Re: non-representable symbols in PE executables

["Jan Beulich" <JBeulich at suse dot com>]

>>> 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.

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