Karthik Bhat
2012-Oct-01 18:22 UTC
[LLVMdev] Wrong type qualifier for this pointer in case of ARM compiled binary
Hi All, Was looking into a simple program - class Simple { public: void fun() {} }; int main() { Simple s; s.fun(); return 0; } When compiled using clang++ for ARM- Expected result when we run - print Simple::fun in GDB is void fun(Simple* const this) as this should be a const pointer but in case of arm compiled binary we get void fun(Simple* this). Works fine when compiled using clang++ for x86. Seems to be problem with qualifier type but was wondering how is this target dependent? Need input from community were can we look to fix this issue for ARM compiled binary. Thanks Karthik
Tim Northover
2012-Oct-02 07:04 UTC
[LLVMdev] Wrong type qualifier for this pointer in case of ARM compiled binary
Hi Karthik,> Expected result when we run - > > print Simple::fun in GDB is > void fun(Simple* const this) > > as this should be a const pointer but in case of arm compiled binary we get > void fun(Simple* this).I believe the actual type is coming from CXXMethodDecl::getThisType, which quotes the standard as saying: // C++ 9.3.2p1: The type of this in a member function of a class X is X*. // If the member function is declared const, the type of this is const X*, // if the member function is declared volatile, the type of this is // volatile X*, and if the member function is declared const volatile, // the type of this is const volatile X*. I.e. no const where you're expecting it. I've checked the standards, and we're not making it up either: both C++11 and C++03 say the same.> Seems to be problem with qualifier type but was wondering how is this > target dependent?I think it's the gdb programs that are printing different things for the same DWARF debug information. Dumping the information from the x86 binary gives: <1><6b>: Abbrev Number: 6 (DW_TAG_class_type) <6c> DW_AT_name : (indirect string, offset: 0x3e): Simple <70> DW_AT_byte_size : 1 <71> DW_AT_decl_file : 1 <72> DW_AT_decl_line : 1 [...] <3><7f>: Abbrev Number: 8 (DW_TAG_formal_parameter) <80> DW_AT_type : <0x86> <84> DW_AT_artificial : 1 <84> DW_AT_object_pointer: 1 <1><86>: Abbrev Number: 9 (DW_TAG_pointer_type) <87> DW_AT_type : <0x6b> The "this" parameter has type "Simple *" as expected, but also has the attribute DW_AT_object_pointer. My guess is that the x86 gdb decides to print it as "const" because of this, but the ARM one doesn't. Hope this helps. Tim.
Karthik Bhat
2012-Oct-02 07:15 UTC
[LLVMdev] Wrong type qualifier for this pointer in case of ARM compiled binary
Hi Tim, Thanks. I just went through the function and yah as you said i looked into the standard and it seems to be as per C++11. Was confused by the documentation at http://msdn.microsoft.com/en-us/library/ytk2ae82.aspx which mentioned this should be always const which may not be right as mentioned at http://stackoverflow.com/questions/6067244/type-of-this-pointer . Thanks for the input. On Tue, Oct 2, 2012 at 12:34 PM, Tim Northover <t.p.northover at gmail.com>wrote:> Hi Karthik, > > > Expected result when we run - > > > > print Simple::fun in GDB is > > void fun(Simple* const this) > > > > as this should be a const pointer but in case of arm compiled binary we > get > > void fun(Simple* this). > > I believe the actual type is coming from CXXMethodDecl::getThisType, > which quotes the standard as saying: > > // C++ 9.3.2p1: The type of this in a member function of a class X is X*. > // If the member function is declared const, the type of this is const > X*, > // if the member function is declared volatile, the type of this is > // volatile X*, and if the member function is declared const volatile, > // the type of this is const volatile X*. > > I.e. no const where you're expecting it. > > I've checked the standards, and we're not making it up either: both > C++11 and C++03 say the same. > > > Seems to be problem with qualifier type but was wondering how is this > > target dependent? > > I think it's the gdb programs that are printing different things for > the same DWARF debug information. Dumping the information from the x86 > binary gives: > > <1><6b>: Abbrev Number: 6 (DW_TAG_class_type) > <6c> DW_AT_name : (indirect string, offset: 0x3e): Simple > <70> DW_AT_byte_size : 1 > <71> DW_AT_decl_file : 1 > <72> DW_AT_decl_line : 1 > [...] > <3><7f>: Abbrev Number: 8 (DW_TAG_formal_parameter) > <80> DW_AT_type : <0x86> > <84> DW_AT_artificial : 1 > <84> DW_AT_object_pointer: 1 > <1><86>: Abbrev Number: 9 (DW_TAG_pointer_type) > <87> DW_AT_type : <0x6b> > > The "this" parameter has type "Simple *" as expected, but also has the > attribute DW_AT_object_pointer. My guess is that the x86 gdb decides > to print it as "const" because of this, but the ARM one doesn't. > > Hope this helps. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121002/415b8b32/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Wrong type qualifier for this pointer in case of ARM compiled binary
- [LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
- [LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
- [LLVMdev] How is variable info retrieved in debugging for executables generated by llvm backend?
- A question to the DWARF experts on symbol indirection