[llvm-dev] SF_Exported vs SF_Hidden

[Lang Hames via llvm-dev]

Hi David,

Thanks for the feedback!  I've reverted r258665 until I understand this
better.

> The linker considers three sources:
> - EXPORTS directives in a .def file given to the linker
> - The linker's /EXPORT option
> - Object files carry a special section, .drectve, which contains
additional flags that the linker takes under consideration.
 __declspec(dllexport) is typically implemented by adding a /EXPORT entry
for a particular symbol in there (e.g. /EXPORT:_foo).

Ok.

> > (2) Is there any situation where 'SF_Exported' isn't just the inverse
of 'SF_Hidden'? Can we get rid of one or the other of those flags?

> I don't believe so.  Normal static functions will have local binding but
default visibility. Such a function would be neither hidden nor exported.

Something feels not-quite-right about this. What are the valid values for
visibility? If's only "hidden" and "default" then we should just need one
flag for that. If SF_Exported is capturing a derived value, maybe we should
just make it a function on the symbol. E.g.:

bool Symbol::isExported() {
  return isGlobal() && !isHidden();
}

Alternatively I've misunderstood the full meaning of SF_Hidden and
SF_Exported. I always just read them as "will this symbol appear in the
symbol table for a linked DSO". Under that reading, a non-hidden,
non-exported symbol doesn't make sense.

>  I believe readobj already dumps this sort of information out, albeit in
object file specific ways.

Ok. I eventually need something that shows the generic flag's value, but
the output format of the tool can be object specific. For other properties
(e.g. "weak") llvm-objdump and llvm-nm suffice, since they query the
generic flags to produce their (format specific) output. If "exported" is
of interest to people I could add it to one of the generic tools. Otherwise
I'll just add it to llvm-rtdyld.

- Lang.


On Sun, Jan 24, 2016 at 4:16 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

>
>
> On Sun, Jan 24, 2016 at 2:47 PM, Lang Hames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Rui, Rafael, Kevin, Nick,
>>
>> In r258665 I added a line to set the SF_Exported flag in COFFObjectFile -
>> the JIT needs this flag to distinguish exported symbols from non-exported
>> ones.
>>
>> In the process of trying to write a test case for that, a couple of
>> questions came up:
>>
>> (1) Previously COFF wasn't setting either SF_Exported or SF_Hidden. What
>> is the linker using to build the export table for DSOs? Is it just checking
>> the COFF flags directly?
>>
>
> The linker considers three sources:
> - EXPORTS directives in a .def file given to the linker
> - The linker's /EXPORT option
> - Object files carry a special section, .drectve, which contains
> additional flags that the linker takes under consideration.
>  __declspec(dllexport) is typically implemented by adding a /EXPORT entry
> for a particular symbol in there (e.g. /EXPORT:_foo).
>
>
>>
>> (2) Is there any situation where 'SF_Exported' isn't just the inverse of
>> 'SF_Hidden'? Can we get rid of one or the other of those flags?
>>
>
> I don't believe so.  Normal static functions will have local binding but
> default visibility. Such a function would be neither hidden nor exported.
>
>
>>
>> (3) It looks like the symbol table dump format in both llvm-objdump and
>> llvm-nm is different for different object file formats. Should we be
>> listing the state of SF_Exported/SF_Hidden (or their format-specific
>> counterparts) in llvm-objdump or llvm-nm? If not, where's the most
>> reasonable place to dump the state of this flag? If nowhere else suits I
>> can add a new symbol-table dumping option to llvm-rtydld to expose this.
>>
>
> I believe readobj already dumps this sort of information out, albeit in
> object file specific ways.
>
>
>>
>> Cheers,
>> Lang.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160124/dc5d37a9/attachment.html>