This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Sparc32 ELF TLS fixes
On Tue, 12 Apr 2005 08:33:53 +0930
Alan Modra <amodra@bigpond.net.au> wrote:
> That sounds like a ld bug. The strings shouldn't have their
> alignment changed. Since gcc is emitting them to a .rodata.str1.8
> section, I'd expect readelf -S sr3.o should show something like
>
> .. .rodata.str1.8 PROGBITS .. .. .. 01 AMS 0 0 8
>
> The section alignment tells the merge code to not reduce string
> alignment below that value.
Right, and sorry for not getting back sooner about this. It does
appear to be a bug in section size assignment in merge_sections().
The section is marked with the correct alignment, and the code
in bfd/merge.c:record_section() is using the correct 8 byte alignment
information (align = 3 and mask = 7).
merge_strings() does not compute the section size correctly in
this loop:
/* Now assign positions to the strings we want to keep. */
size = 0;
secinfo = sinfo->htab->first->secinfo;
for (e = sinfo->htab->first; e; e = e->next)
{
if (e->secinfo != secinfo)
{
secinfo->sec->size = size;
secinfo = e->secinfo;
}
if (e->alignment)
{
if (e->secinfo->first_str == NULL)
{
e->secinfo->first_str = e;
size = 0;
}
size = (size + e->alignment - 1) & ~((bfd_vma) e->alignment - 1);
e->u.index = size;
size += e->len;
}
}
secinfo->sec->size = size;
For the test case we end up with size at 27 which is not aligned to
a multiple of 8 of course.
Alan, this problem seems to have been introduced by your _raw_size changes
(revision 1.20 --> 1.21 of bfd/merge.c on June 24, 2004). That line at the
end of the loop quoted above which sets "secinfo->sec->size = size;" came
from those changes.