[llvm-dev] SF_Exported vs SF_Hidden

[David Majnemer via llvm-dev]

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/88e23ecc/attachment.html>