Re: GCC -pie patch (kinda) ....

[Michael Schmitz <schmitz@onyx.biophys.uni-duesseldorf.de>]

> Right now, I've developed a no-op patch, but its just a fugly way to work
> around the problem, which I haven't fully idenified yet. The problem stems
> from glibc, from csu/elf-init.c
>
> #ifdef HAVE_INITFINI_ARRAY
> /* These magic symbols are provided by the linker.  */
> extern void (*__preinit_array_start []) (void) attribute_hidden;
> extern void (*__preinit_array_end []) (void) attribute_hidden;
> extern void (*__init_array_start []) (void) attribute_hidden;
> extern void (*__init_array_end []) (void) attribute_hidden;
> extern void (*__fini_array_start []) (void) attribute_hidden;
> extern void (*__fini_array_end []) (void) attribute_hidden;
> #endif
>
> /* These function symbols are provided for the .init/.fini section entry
>       points automagically by the linker.  */
> extern void _init (void);
> extern void _fini (void);
>
> HAVE_INITFINI_ARRAY is determined on the fly by autotools at compile time
> to tell if the linker supports ELF sections  .init_array, .finit_array,
> and .preinit_array. From what I can tell by reading binutils linker
> scripts, this SHOULD be supported on any platform that has ELF support,
> but I can't determine it for sure (binutils linker scripts give me a
> headache).

>From what I recall, the linker is supposed to generate these sections but
apparently the necessary sections in the object files are missing.

> It's possible that since we do not support TLS, our linker no longer
> supports these, in which case the proper course of action would be
> to fix it in glibc, otherwise, figure out why binutils isn't outputting
> these sections into the resulting binary files. My next course of action
> is to dive into the ELF specification (bleck), and figure out what, if
> anything these sections do, but its quite possible this task is over my
> head. In addition, by making -pie a no-op, we at least have a fix.

It may well be that init and fini sections are specific to TLS. We might
get asm to just add empty stubs in order to keep ld happy.

> I'll post the no-op patch if its wanted, and if anyone has ANY idea where
> I should look, or any thoughts and suggestions, it would be greatly

I couldn't figure out whether to look at ld, gcc or libc last time I
started on it. TLS support for an architecture similar to m68k might have
some useful hints ...

	Michael