SF_Exported vs SF_Hidden

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?

(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?

(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.

Cheers,
Lang.

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.

Hi David,

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

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 don't think the "object format abstracted" flags have a very well
defined meaning and don't get a lot of use. Since you are one of the
few users, feel free to refine them.

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.

The output format of llvm-nm and llvm-objdump is pretty locked given
that we want them to match the native nm and objdump.

It could be done in llvm-readobj, but that one is designed to dump
pretty much everything, so it is format specific.

llvm-rtdyld seems to be the winner.

Cheers,
Rafael

> 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 don't think the "object format abstracted" flags have a very well
defined meaning and don't get a lot of use. Since you are one of the
few users, feel free to refine them.

Yes. We at least don't use that in our COFF linker, so I don't have an
opinion on it. I think you can change that as long as it makes sense to you
(and to other people who are using the fields.)

Thanks guys!

I don’t think the “object format abstracted” flags have a very well
defined meaning and don’t get a lot of use. Since you are one of the
few users, feel free to refine them.

Great. For now I’m going to get rid of “Exported” and rely on Hidden. In the longer term I hope to get rid of this flag altogether (given that it’s not well defined) and teach the JIT linker to understand each format’s flags. I’ll add the necessary test infrastructure to llvm-rtdyld.

  • Lang.