[PATCH] ELF: Don't check DT_NEEDED for linker script defined symbols

Alan Modra amodra@gmail.com
Sun Nov 26 20:43:00 GMT 2017


On Sun, Nov 26, 2017 at 07:14:59AM -0800, H.J. Lu wrote:
> On Sat, Nov 25, 2017 at 4:12 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> > On Thu, 23 Nov 2017, H.J. Lu wrote:
> >
> >> Linker shouldn't use any shared objects, including those from DT_NEEDED,
> >> to resolve references of symbols which will be defined by linker script.
> >
> > Here you say "linker script", later you say "built-in linker
> > script".  ITYM the former everywhere; at least that's what makes
> > sense to me.
> 
> It should be default linker scripts used by linker.   They can be either
> builtin or read from disk.
> 
> >> +      const char *symbols[] =
> >> +     {
> >> +       "__${ETEXT_NAME}",
> >> +       "_${ETEXT_NAME}",
> >> +       "${ETEXT_NAME}",
> >> +       "${USER_LABEL_PREFIX}" "__bss_start",
> >> +       "${USER_LABEL_PREFIX}" "_edata",
> >> +       "${USER_LABEL_PREFIX}" "edata",
> >> +       "${USER_LABEL_PREFIX}" "_end",
> >> +       "${USER_LABEL_PREFIX}" "end",
> >> +       NULL
> >> +     };
> >
> > This isn't derived from command-line-specified linker scripts in
> > effect, this is a static, somewhat arbitrary list.
> >
> 
> This list comes from default linker script used by linker.  It isn't
> used for command-line-specified linker scripts since linker hasn't
> parsed linker script yet.  Linker knows what symbols will be defined
> only when the default linker script is used.
> 
> Here is the updated patch to cover default linker script on disk.

This is just getting more horrible.  What the PR is really
demonstrating is that the error is emitted too early.  I don't know
how hard it would be to delay the error until later, but I suspect
that isn't easy.  I'd say that acceptable solutions are:
1) Remove the error entirely.
2) Downgrade the error to a warning.
3) Process link script assignments earlier.

We already process some assignments in open_input_bfds to have
--defsym symbols defined early, so (3) shouldn't be too hard.

-- 
Alan Modra
Australia Development Lab, IBM



More information about the Binutils mailing list