[llvm-dev] SF_Exported vs SF_Hidden

[Lang Hames via llvm-dev]

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.

On Mon, Jan 25, 2016 at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote:

> 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/1c930d4c/attachment.html>