This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Sparc32 ELF TLS fixes


On Sun, 10 Apr 2005 19:45:22 -0700
"David S. Miller" <davem@davemloft.net> wrote:

> On Mon, 11 Apr 2005 11:19:26 +0930
> Alan Modra <amodra@bigpond.net.au> wrote:
> 
> > It might simply be that the two bss sections start at different
> > addresses.  Perhaps they have different alignments for some reason.
> > Perhaps a different start address is caused by pruning of unused
> > sections in the ELF linker but not the SREC one.
> 
> That's a good guess.  The elf32-sparc BFD backend does garbage
> collection.
> 
> I'll look more deeply into this.

The sizing of the .rodata section changes.  When outputting elf it
gets a size of 0x1b, but when outputting SREC it gets sized to
32.

Regardless of the cause for this .rodata size different, the net
effect is that the .bss will be at a different offset and thus the
relocations we talked about yesterday will change.

This change in output .rodata size is because, at size_input_section()
time, the input .rodata section is seen as having a different size.
In the ELF output case it is 27, in the SREC output case it is 32.

[ ... more fuddling around in gdb ... ]

The .rodata starts as .rodata.str1.8 in sr3.o:

Contents of section .rodata.str1.8:
 0000 6175746f 6d617469 635f666f 6f000000  automatic_foo...
 0010 73746174 69635f66 6f6f0000 00000000  static_foo......

It is in fact 32 bytes.  But something causes it to shrink when
outputting ELF.  And this something is _bfd_elf_merge_sections().
The above is the only .rodata.* section, so it is the only one
processed during _bfd_merge_sections().  It trims the strings so
that there are no spurious NULL bytes.  And that's how we end up
with a 27 byte .rodata output section from the original 32 byte
input section.

I don't see any reasonable way to fix this besides possibly disabling
section merging via command line option for this test case.  Is there
even a way to turn SEC_MERGE processing off from the ld command line?

Alan?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]