Re: [RFC] Providing init_fini_syms earlier?

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Jul 07, 2005 at 04:03:45PM -0400, Daniel Jacobowitz wrote:
> On Thu, Jul 07, 2005 at 10:40:49AM -0700, H. J. Lu wrote:
> > > My pleasure.
> > > 
> > > http://www.baldric.uwo.ca/~carlos/bug-extraNONE.tar.gz
> > > 
> > > Contains everything you need to test the bug in a cross link
> > > environment. You will see that two extra R_PARISC_NONE relocs are
> > > emitted, and they correspond to the undefined __init_array_start and
> > > __init_array_end.
> > > 
> > > If the linker doesn't provide the symbols early enough the bakends can't
> > > do the work of ignoring them? :)
> > 
> > That is the libc bug on hppa. __init_array_start and __init_array_end
> > should be used ONLY for building STATIC executables. Please check out
> > how ia32, x86-64 and ia64 handle them.
> 
> How can a linker generating unnecessary R_PARISC_NONE relocs be a
> library bug?  The linker needs to behave correctly on any input.

1. R_PARISC_NONE shouldn't cause any problems.
2. __init_array_start/__init_array_end are provided by linker for
static exexcutables since DT_INIT_ARRAY isn't available.

When __init_array_start/__init_array_end are used for non-static
exexcutable, linker generates working outputs. I don't see a problem.


H.J.