ld/emulparams/sparc*.sh NOP missing in all but one file

ld/emulparams/sparc*.sh NOP missing in all but one file

[Joel Sherrill]

Hi,

I am noticing semi-random values for SPARC
executables when inserting nops for alignment
between methods.  Doing a grep, I see that
only one emulparams file for SPARC has a NOP
pattern

elf64_sparc.sh:NOP=0x01000000

Shouldn't the rest of the sparc files have this
also?

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: ld/emulparams/sparc*.sh NOP missing in all but one file

[Joel Sherrill]

On 05/26/2010 12:34 PM, Joel Sherrill wrote:
> Hi,
>
> I am noticing semi-random values for SPARC
> executables when inserting nops for alignment
> between methods.  Doing a grep, I see that
> only one emulparams file for SPARC has a NOP
> pattern
>
> elf64_sparc.sh:NOP=0x01000000
>
> Shouldn't the rest of the sparc files have this
> also?
>
>    
I have modified elf32_sparc.sh to add this line:

NOP=0x01000000

That is showing up as the =XXX fill pattern in the
ld scripts.  But it does not seem ld in binutils 2.20.1
is honoring it.  This is the disassembly from objdump.
Even the address for the call is bogus.

4000db40:       81 c7 e0 08     ret
4000db44:       81 e8 00 00     restore
4000db48:       40 00 dc 74     call  40044d18 <_end+0x268c0>
4000db4c:       40 00 dc 94     call  40044d9c <_end+0x26944>
4000db50:       40 00 dc 8c     call  40044d80 <_end+0x26928>
4000db54:       40 00 dc 8c     call  40044d84 <_end+0x2692c>
4000db58:       40 00 dc b4     call  40044e28 <_end+0x269d0>
4000db5c:       40 00 dc a8     call  40044dfc <_end+0x269a4>
4000db60:       40 00 dc cc     call  40044e90 <_end+0x26a38>

Any ideas on what to look for that might be going wrong?

--joel

Re: ld/emulparams/sparc*.sh NOP missing in all but one file

[David Miller]

From: Joel Sherrill <joel.sherrill@oarcorp.com>
Date: Wed, 26 May 2010 14:16:09 -0500

> I have modified elf32_sparc.sh to add this line:
> 
> NOP=0x01000000

Did you rebuild the 'ld' binary and use that for your tests?  The
scripts get transformed into "eelf*_sparc.c" files and then built and
linked into the final linker image.

I'm pretty sure you did this, but I just wanted to make sure :-)

Changing elf32_sparc.sh to have the NOP setting and rebuilding 'ld'
works for me here:

-------------------- x.s --------------------
        .text
        .globl  foo
foo:
        .align  64
        sethi   %hi(0x000001), %g1
        .align  64
        sethi   %hi(0x000002), %g2
---------------------------------------------
davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ gcc -c -o x.o x.s
davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ ./ld/ld-new -r -o y.o x.o
davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ objdump --full-contents y.o

y.o:     file format elf32-sparc

Contents of section .text:
 0000 03000000 01000000 01000000 01000000  ................
 0010 01000000 01000000 01000000 01000000  ................
 0020 01000000 01000000 01000000 01000000  ................
 0030 01000000 01000000 01000000 01000000  ................
 0040 05000000 01000000 01000000 01000000  ................
 0050 01000000 01000000 01000000 01000000  ................
 0060 01000000 01000000 01000000 01000000  ................
 0070 01000000 01000000 01000000 01000000  ................
davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ 

Re: ld/emulparams/sparc*.sh NOP missing in all but one file

[Joel Sherrill]

On 05/26/2010 11:02 PM, David Miller wrote:
> From: Joel Sherrill<joel.sherrill@oarcorp.com>
> Date: Wed, 26 May 2010 14:16:09 -0500
>
>    
>> I have modified elf32_sparc.sh to add this line:
>>
>> NOP=0x01000000
>>      
> Did you rebuild the 'ld' binary and use that for your tests?  The
> scripts get transformed into "eelf*_sparc.c" files and then built and
> linked into the final linker image.
>
>    
I am seeing the not-NOPs at the end of a method
where there is padding to get to the start of the next
method.

So this is between two .o's.  I have created a
test case which has the two precompiled .o's
and an "undefined.c" precompiled for you.

There is a script c to link them into "t".

sparc-rtems4.10-ld -T linkcmds -o t imfs_chown.o imfs_creat.o und.o

and if you objdump t, you see the problem
at the end of the first method.

I am sure there has to be a good explanation
of what I am doing wrong.  All I did was add
NOP=0x01000000 to elf32_sparc.sh, make clean,
configure and install.

The date on the installed ld changed.

Maybe you can spot something.


> I'm pretty sure you did this, but I just wanted to make sure :-)
>
>    
Yes.  I am nearly 100% positive but it was good to ask.
> Changing elf32_sparc.sh to have the NOP setting and rebuilding 'ld'
> works for me here:
>
> -------------------- x.s --------------------
>          .text
>          .globl  foo
> foo:
>          .align  64
>          sethi   %hi(0x000001), %g1
>          .align  64
>          sethi   %hi(0x000002), %g2
> ---------------------------------------------
> davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ gcc -c -o x.o x.s
> davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ ./ld/ld-new -r -o y.o x.o
> davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$ objdump --full-contents y.o
>
> y.o:     file format elf32-sparc
>
> Contents of section .text:
>   0000 03000000 01000000 01000000 01000000  ................
>   0010 01000000 01000000 01000000 01000000  ................
>   0020 01000000 01000000 01000000 01000000  ................
>   0030 01000000 01000000 01000000 01000000  ................
>   0040 05000000 01000000 01000000 01000000  ................
>   0050 01000000 01000000 01000000 01000000  ................
>   0060 01000000 01000000 01000000 01000000  ................
>   0070 01000000 01000000 01000000 01000000  ................
> davem@maramba:~/src/GIT/BINUTILS/build-sparc-linux$
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: ld/emulparams/sparc*.sh NOP missing in all but one file

[David Miller]

From: Joel Sherrill <joel.sherrill@oarcorp.com>
Date: Thu, 3 Jun 2010 17:07:28 -0500

> I am seeing the not-NOPs at the end of a method
> where there is padding to get to the start of the next
> method.
> 
> So this is between two .o's.  I have created a
> test case which has the two precompiled .o's
> and an "undefined.c" precompiled for you.
> 
> There is a script c to link them into "t".
> 
> sparc-rtems4.10-ld -T linkcmds -o t imfs_chown.o imfs_creat.o und.o
> 
> and if you objdump t, you see the problem
> at the end of the first method.

If you want me to look at this, where is this test case?

I didn't see it in an attachment to this posting.

Re: ld/emulparams/sparc*.sh NOP missing in all but one file

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On 06/03/2010 08:20 PM, David Miller wrote:
> From: Joel Sherrill<joel.sherrill@oarcorp.com>
> Date: Thu, 3 Jun 2010 17:07:28 -0500
>
>    
>> I am seeing the not-NOPs at the end of a method
>> where there is padding to get to the start of the next
>> method.
>>
>> So this is between two .o's.  I have created a
>> test case which has the two precompiled .o's
>> and an "undefined.c" precompiled for you.
>>
>> There is a script c to link them into "t".
>>
>> sparc-rtems4.10-ld -T linkcmds -o t imfs_chown.o imfs_creat.o und.o
>>
>> and if you objdump t, you see the problem
>> at the end of the first method.
>>      
> If you want me to look at this, where is this test case?
>
>    
Thanks for looking at this.
> I didn't see it in an attachment to this posting.
>    
Grrr.. should be test.tar.bz2 attached.

--joel

[-- Attachment #2: test.tar.bz2 --]
[-- Type: application/x-bzip, Size: 14329 bytes --]

Re: ld/emulparams/sparc*.sh NOP missing in all but one file

[David Miller]

From: Joel Sherrill <joel.sherrill@oarcorp.com>
Date: Thu, 3 Jun 2010 20:23:39 -0500

> Thanks for looking at this.

Those things you see after the final instructions of IMFS_chown are
not padding, they are some set of references to other locations in
the binary.

My best guess is that this is a local table of code addresses used by
the switch() statement in the code for IMFS_create_node().

And this makes sense since the next symbol after IMFS_chown is in
the same section (.text) and the .text sections in all of the input
objects have the same alignment (2*2 == 4 bytes) which on sparc
should never require alignment padding since all instructions are
4 bytes in size and 4 byte aligned.

In the case where real padding actually got created by the linker, for
the gap at the end of strncpy() leading up to __start_set_sysctl_set,
where a directive stating ". = ALIGN(16)" occurs in the linker script,
the proper nops were emitted once elf32_sparc.sh has the proper NOP
statement added.

Anyways, when I get a chance I'll commit that NOP addition to the tree.