This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: non-representable symbols in PE executables
On Mon, Jul 04, 2016 at 01:54:14AM -0600, Jan Beulich wrote:
> >>> On 04.07.16 at 04:11, <amodra@gmail.com> wrote:
> > On Tue, Jun 28, 2016 at 12:38:13AM -0600, Jan Beulich wrote:
> >> --- a/ld/ldexp.c
> >> +++ b/ld/ldexp.c
> >> @@ -1181,7 +1181,7 @@ exp_fold_tree_1 (etree_type *tree)
> >> h->type = bfd_link_hash_defined;
> >> h->u.def.value = expld.result.value;
> >> h->u.def.section = expld.result.section;
> >> - h->linker_def = 0;
> >> + h->linker_def = ! tree->assign.type.lineno;
> >> if (tree->type.node_class == etree_provide)
> >> tree->type.node_class = etree_provided;
> >>
> >
> > linker_def is supposed to indicate that a symbol is a built-in define,
> > ie. defined somewhat magically by the linker rather than by an object
> > file, linker script, or on the command line.
>
> That's what the purpose of the changed logic is.
>
> > Please convince me that
> > lineno is always non-zero when parsing a script or the command line,
> > and always zero otherwise. I'm particularly interested in what
> > happens on the first line of a script.
>
> Indeed that's something I did consider possibly needing an additional
> adjustment somewhere, after having sent the original mail. Yet both
> lex_push_file() and ldfile_open_command_file_1() already set lineno
> to 1, so I think we're covered.
Ah, that's what I needed to know to be convinced the patch is good.
I think you could commit the ldlex.l and ldexp.c change even if you
decide to not go ahead with the coff backend change.
>
> And the change to <<EOF>> in ldlex.l makes sure it's always zero
> afterwards. The only problem would by symbols the linker generates
> _while_ handling a script, but I think if such exist they would need to
> be handled on a case by case basis - current behavior for such
> symbols simply wouldn't change with the patch as is.
>
> Jan
>
--
Alan Modra
Australia Development Lab, IBM