[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