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>