On Thu, Feb 16, 2012 at 1:32 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
> <r...@cebitec.uni-bielefeld.de> wrote:
>> Paolo Bonzini <bonz...@gnu.org> writes:
>>
>>> This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
>>> gcc_AC_INITFINI_ARRAY.
>>
>> Here's an updated patch that does so. During testing, I found one
>> additional complication, though. With the Sun as/GNU ld combination on
>> Solaris 11/x86, after the bootstrap had completed, all programs linked
>> against libgcc_s.so.1 SEGVed with a stacktrace like this:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1 (LWP 1)]
>> 0x00002000 in ?? ()
>> (gdb) where
>> #0 0x00002000 in ?? ()
>> #1 0xfefcd73f in call_array () from /usr/lib/ld.so.1
>> #2 0xfefcd8bd in call_init () from /usr/lib/ld.so.1
>> #3 0xfefcc8e1 in setup () from /usr/lib/ld.so.1
>> #4 0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
>> #5 0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
>> #6 0x0804796c in ?? ()
>> #7 0x08047ab0 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>
>> The problem turned out to be that with
>>
>> .section .init_array
>>
>> as generates
>>
>> Section Header[5]: sh_name: .init_array
>> sh_addr: 0 sh_flags: 0
>> sh_size: 0x4 sh_type: [ SHT_PROGBITS ]
>> sh_offset: 0x344 sh_entsize: 0
>> sh_link: 0 sh_info: 0
>> sh_addralign: 0x4
>>
>> i.e. empty sh_flags. gld seems to mishandle this, since the
>> corresponding .initarray entry is bad, as can be seen with runtime
>> linker debugging:
>>
>> $ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
>> [...]
>> 02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
>> 02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
>> Segmentation Fault
>>
>> If I change the above to
>>
>> .section .init_array,"aw",@progbits
>>
>> everything works fine with as/gld, but breaks again with gas/gld since
>> gas warns about @progbits here. It turned out that
>>
>> .section .init_array,"aw"
>>
>> is fine with both assemblers, while as doesn't understand @init_array.
>> That's what the patch below uses.
>>
>>> Can you test Linux too? The change of -e0 looks good, but I'd rather check
>>> on the actual system.
>>
>> This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
>> as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
>> x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
>> on the gld configurations. It was also included with
>> sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
>> test fails. I've got to investigate that separately.
>
> I'm not sure about the varasm.c change - it's definitely not a no-op
> (callback will be not set, and the flags will be different). Certainly
> the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
> case, not sure why, but you don't make it consistent either because
> you don't change that case to SECTION_NOTYPE either. I'd be fine
> with it with both calls using SECTION_NOTYPE, but would like to
> know what the callback difference is about.
>
> HJ, can you shed some light on this?
>
GNU assembler understands:
.section .init_array*
If Solaris assembler doesn't, I don't know how it will work
with .init_array with priority.
--
H.J.
