[RFC] Removing DefinedSynthetic

[Dave Bozier via llvm-commits]

> DefinedSynthetic is being used to define linker-synthesized symbols that
are relative to output sections. _end or _edata are a few examples.

Given that SyntheticSection are InputSections, wouldn't it make sense to
make DefinedSynthetic to be defined relative to input sections to be
consistent?

On Wed, Feb 22, 2017 at 6:20 PM, Rui Ueyama via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Wed, Feb 22, 2017 at 9:43 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> I am looking at https://bugs.llvm.org/show_bug.cgi?id=32031 and there
>> are a couple of ways to interpret it.
>>
>> One way is that we are just computing symbol values too early. When we
>> do it some output sections still don't have their address set and some
>> input sections still don't know what output section they will be in.
>>
>> The other way to look at it is just that our representation of symbol
>> values in the linker script is wrong. I started experimenting with using
>> a ExprValue struct that is similar in idea to a MCValue. It is what Expr
>> returns and it contains a PointerUnion of an input or output section and
>> the offset. This allows us to avoid having to check the OutSec field
>> before it is set and solves the problem.
>>
>> But that got me thinking, can we remove DefinedSynthetic completely?
>> With the addition of a few dummy input sections and potentially a couple
>> more conversions to SyntheticSection I think we can.
>>
>
> Regular Defined symbols are defined relative to input sections because
> they are both read from input files. Regular symbols get their addresses
> when the associated input sections get addresses.
>
> DefinedSynthetic is being used to define linker-synthesized symbols that
> are relative to output sections. _end or _edata are a few examples.
>
> So, if you remove DefinedSynthetic, how do you represent _end, for example?
>
>
>> Can anyone think of a reason why this would not work?
>>
>> Cheers,
>> Rafael
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170222/59c0a7e6/attachment.html>