[lld] r286713 - [ELF] - Add support for locals list in version script.
Rafael EspĂndola via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 16 07:47:03 PST 2016
On 16 November 2016 at 04:19, George Rimar <grimar at accesssoftek.com> wrote:
>>"local:" is special in that it is not actually part of any version.
>>Having two "local: *" will not change the result. I would then suggest
>>moving the Locals vector out of VersionDefinition and into
>>Configuration.
>>
>>Cheers,
>>Rafael
>
> After some investigations:
> 1) This change *can* affect on result in next case:
>
> Version1 {
> global:
> <wildcarded globals 1>
> local:
> <wildcarded locals 1>
> }
> Version2 {
> global:
> <wildcarded globals 2>
> local:
> <wildcarded locals 2>
> }
>
> If we would have single list of locals, we would process them either before or after lists of globals.
> In both cases that is not the same as we had, for example previously order was:
>
> <wildcarded locals 2> <wildcarded globals 2> <wildcarded locals 1> <wildcarded globals 1>
>
> So after such change it will be one of 2:
> <wildcarded locals N> <wildcarded locals N2 > <wildcarded globals 2> <wildcarded globals 1>
> <wildcarded globals 2> <wildcarded globals 1> <wildcarded locals N> <wildcarded locals N2 >
> That would be a deviation from GNU behavior.
>
> 2) Also this will affect on error reporting. Since when we will have a single list of locals and do not have a maping
> local->versionN, it will be problematic to report something like "symbol has version X but was declared as local in version Y",
> though we can skip "in version Y" here.
>
> Now I am not sure it worth doing that, do you still in favor or doing such change ?
Probably. We have usually gone with the simplest solution possible,
and it is a sad design decision that locals are part of a version in
version scripts.
Cheers,
Rafael
More information about the llvm-commits
mailing list