[LLVMdev] No location info for artificial arguments: cannot step into class methods

Oleg Ranevskyy llvm.mail.list at gmail.com
Sun Jun 28 09:27:13 PDT 2015


Hi David,

It doesn't reproduce on X86 due to the differences in emitPrologue for 
ARM and X86. While ARMFrameLowering::emitPrologue initializes debug 
location:
    DebugLoc dl = MBBI != MBB.end() ? MBBI->getDebugLoc() : DebugLoc();
X86FrameLowering::emitPrologue leaves its default value:
    DebugLoc DL;
ARMFrameLowering::emitPushInst has the same problem.
Leaving it unitialized looks like a hack.

Taking this into account, could you review if the r188651 patch is fully 
correct, please?

Thanks.

25.06.2015 15:47, Oleg Ranevskyy пишет:
>
>> On Wed, Jun 24, 2015 at 2:28 PM, Oleg Ranevskyy 
>> <llvm.mail.list at gmail.com <mailto:llvm.mail.list at gmail.com>> wrote:
>>
>>     Hi David,
>>
>>     I got a problem related to the change made in r188651 - not
>>     including file/line info for artificial arguments like "this" and
>>     "self".
>>     Would you be able to take a look at it, please?
>>
>>
>> Could you provide a simple test case? (& ideally: does this reproduce 
>> on X86, a platform I've easy access to (& if it doesn't, I'd be 
>> curious to understand why not...))
> Sure. It's enough to have a simple class with a constructor and create 
> its instance.
> Compile it w/o fast ISel, e.g.: clang -g -O0 main.cpp 
> --target=armv7l-unknown-linux-gnueabihf -mllvm -fast-isel=0
>
> class MyClass
> {
> public:
>     MyClass()
>     {
>     }
> };
> int main()
> {
>     MyClass obj;   // <-- can't step into MyClass::MyClass() here
>     return 0;
> }
>
> It didn't reproduce on X86_64 though. I will try to find out why.
>>
>>     I am compiling the code for ARM linux with fast ISel disabled:
>>     -mllvm -fast-isel=0. The problem is that it's not possible to
>>     step intothe constructor, destructor or a method of a class while
>>     debugging. Clang generates correct .loc in function prologues,
>>     but then,  due to r188651, inserts a debug info location with
>>     zeroed line number (.loc 1 0 0) for "this", which misleads the
>>     debugger.
>>
>>     Could you explain the reasoning behind this change, please?
>>
>>
>> The reason for the change, if I recall correctly (perhaps I mentioned 
>> in the commit message, I'm not sure) was to reduce debug info size 
>> for the debug_info section - I don't believe the intent was to have 
>> any impact on the line table.
>>
>> (artificial variables, like "this" don't have a location they are 
>> declared on, so there was/is no need to have a DW_AT_decl_file/line 
>> in the debug_info describing their declaration location)
> I see, thanks.
> The r188651 patch leads to inserting ".loc    1 0 0" into the 
> constructor's code. Here is a part of the assembly I get for the 
> MyClass constructor:
>
> _ZN7MyClassC2Ev:                        @ @_ZN7MyClassC2Ev
> .Lfunc_begin1:
>     .loc    1 7 0                   @ main.cpp:7:0
>     .fnstart
>     .cfi_startproc
> @ BB#0:                                 @ %entry
>     .loc    1 0 0                   @ main.cpp:0:0 <-------------- loc 
> with line == 0 confuses the debugger
>     .pad    #4
>     sub    sp, sp, #4
>     ....
>
> Fast ISel removes this ".loc    1 0 0", so the debugger successfully 
> steps into the constructor due to the previous ".loc    1 7 0".
>>
>>
>>     This hasn't been noticed before due to the fast ISel omitting
>>     location info for arguments, so the correct location from the
>>     prologue is used. It is probably yet another problem to handle.
>>
>>     Thanks in advance for any help.
>>     Kind regards,
>>     Oleg
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150628/3c1b2552/attachment.html>


More information about the llvm-dev mailing list