This is the mail archive of the
mailing list for the binutils project.
Re: non-representable symbols in PE executables
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Alan Modra" <amodra at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 04 Jul 2016 01:54:14 -0600
- Subject: Re: non-representable symbols in PE executables
- Authentication-results: sourceware.org; auth=none
- References: <5772377502000078000F942F@prv-mh.provo.novell.com> <20160704021109.GE6605@bubble.grove.modra.org>
>>> On 04.07.16 at 04:11, <email@example.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.
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.