[llvm] r191225 - Handle gnu pubtypes sections:
echristo at gmail.com
Mon Sep 23 14:37:06 PDT 2013
Appears to be so. Compiling the same file with gcc for it gives this:
Offset in .debug_info: 0
Offset Linkage Kind Name
0x00000054 EXTERNAL FUNCTION "C::member_function"
0x0000007c EXTERNAL FUNCTION "C::static_member_function"
0x0000008d EXTERNAL FUNCTION "global_function"
0x000000a1 EXTERNAL TYPE "ns"
0x000000ab EXTERNAL FUNCTION "ns::global_namespace_function"
0x000000ba EXTERNAL FUNCTION "ns::global_namespace_function"
0x000000ca EXTERNAL VARIABLE "global_variable"
0x000000d5 EXTERNAL VARIABLE "ns::global_namespace_variable"
0x000000dd EXTERNAL VARIABLE "C::static_member_variable"
which definitely has a type in pubnames.
On Mon, Sep 23, 2013 at 2:21 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Mon, Sep 23, 2013 at 2:19 PM, Eric Christopher <echristo at gmail.com>
>> > I take it we should be seeing that type (which type is it? 'C' I guess?)
>> > in
>> > the pubnames section too? (we had no types being checked for, nor
>> > emitted,
>> > in the test as originally committed - I assume that's a bug? but I had
>> > seen
>> > types emitted in some cases I'd been experimenting with)
>> Oddly enough, apparently not. We should be emitting qualified names as
>> I mentioned the other day, that's the only place that C is appearing
>> in the gnu pubnames section as emitted by gcc.
> You mean "C" is only appearing in the context of some fully qualified name
> of one of C's member functions? OK.
> But could we have a test case for some type in the pubnames section
> (something where the descriminator is 'type' rather than 'function' or
>> And yeah, that we weren't emitting, well anything, into the right
>> section was the bug :)
>> > I'll look into adding dumping support for pubtypes.
More information about the llvm-commits