RE: binutils-2.15 - work around for gcc optimization problem on s parc-sun-solaris2.7

[Kelvin Lee]

Eventually, I figured out what's the real problem.
In line 2703, if the difference (in term of bytes) between the 2 pointers is not of multiple to the size of the structure (asection in this case) pointed to by the pointers, the calculation would return weird values.

For comparison, the default cc of Solaris would return truncated difference between the 2 pointers. That's why the problem happens only for gcc.

So the question becomes if the pointers are expected to be properly aligned.

Regards,
Kelvin Lee
// LANSA Product Centre
// LANSA Pty Ltd
// phone: +61 (2) 8907 0231
// mailto:address@hidden

> -----Original Message-----
> From: Kelvin Lee
> Sent: Tuesday, June 29, 2004 4:41 PM
> To: 'address@hidden'; 'address@hidden'
> Subject: binutils-2.15 - work around for gcc optimization problem on
> sparc-sun-solaris2.7
>
>
> When I am building binutils-2.15 on sparc-sun-solaris2.7
> using gcc-3.4, it seems the combination triggered a bug of
> gcc that would generate incorrect code for the function
> elf_sort_symbol() of bfd/elflink.c. At elflink.c line 2703
> inside elf_sort_symbol(), the calculation of sdiff would be
> wrong and hence confusing qsort() and causing ld to crash in
> some situations. In my case, ld crashed when it was used to
> build gcc-3.4.
>
> Attached test.c is code extracted from elflink.c to
> demonstrate the problem. You can use attached comp.sh to
> compile the test program. The test program must be compile
> inside the bfd directory of the binutils-2.15 package. The
> embedded data is the data extract from the gcc-3.4 build
> which caused ld-2.15 to crash. BTW, the test program also
> shows a possible work around of the problem, i.e. instead of
> doing the calculation, simply comparing the values inside
> elf_sort_symbol. (You may also use the attached diff file to
> patch elflink.c.) The patch seems working fine or at least
> survived the gcc build cycle.
>
> Notes:
> 1. gcc-2.95 and gcc-3.3 also generate incorrect code for
> elf_sort_symbol(). You can verify that with my test program.
> 2. The qsort() comes with Solaris does not seem to be robust
> enough against this kind of confusing comparing results.
> Replacing that with other implementation of qsort() does not
> cause crashing but the comparisons were wrong anyway.
> 3. Also the qsort() crashing also depends gcc optimization
> level and data surrounding the data to be sorted. See my test
> program which I need to add some dummy variables to cause
> crashing if no optimization is used.
>
> Regards,
> Kelvin Lee
> // LANSA Product Centre
> // LANSA Pty Ltd
> // phone: +61 (2) 8907 0231
> // mailto:address@hidden
>