[llvm-dev] SF_Exported vs SF_Hidden

[Rui Ueyama via llvm-dev]

On Mon, Jan 25, 2016 at 10:01 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

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


> >>  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160125/748ece31/attachment.html>