[llvm-dev] LLVM IR Debugger
UE US via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 4 04:16:11 PST 2018
I worked with LLVM for years and never knew there was an IR debugger. At
that stage of my time with it lowering issues / crashes were a bigger
problem than code, and assembly language can be correlated to IR in my head
pretty accurately because I'm strange that way, so I never looked. I don't
use it as much anymore but I'm sure some people would be interested.
If the IR won't lower, this pass won't work, correct? As I said I'm
To play devil's advocate, what happens if you need to debug IR from 2 years
ago or an unknown build? As long as the IR is compatible the two years
situation works, but if it doesn't and for whatever catastrophe that's all
you have, what do you do about it? IR could be the cause of a bug in one
revision and a subtle fix makes it pointless to debug two revisions later
without breaking anything and vice versa.
It doesn't happen as much anymore, but it happens. That was kind of a
rhetorical question since I already know what happens when you mix somewhat
compatible IR versions.
Since I'm not familiar with the original pass, does this step through *and*
attempt lowering? I know we need an MBB to lower, but being able to ID
the exact line of IR causing the lowering error could help nicely. At O0
there isn't much going on in terms of block changes so it seems reasonable
to match up an error to the producing line from what I know of the debug
system. There would be problems (Dummy MBBs for targets / unseen preds off
the top of my head), but it would be a step up from doing pass debugging
Since you're more familiar with this, how hard do you think implementing
something like that would be, on a scale of 1 to go away with that
On Thu, Jan 4, 2018 at 2:09 AM, Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 4 January 2018 at 07:11, Brenda So via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > interesting ... just curious, why did they delete "-debug-ir" to begin
> with ?
> The metadata describing the information debuggers need (line numbers,
> variable locations and so on) was evolving rapidly at the time I
> think. The -debug-ir pass was lagging behind I think, and rarely used
> as far as anyone knew.
> > Also, it's extremely interesting that gdb and lldb can be used to debug
> LLVM IR. How does your code work (on a high level)? A high level
> explanation will help me understand what you've done better.
> It adds the information necessary to produce normal DWARF debugging
> information in the object files. That format is designed to be
> One part is just mapping some byte of the output instructions back to
> the source file and line number, which is just as easy for IR as for a
> more conventional language. The other major part is describing where
> in memory or registers named variables are, which is also pretty much
> the same for LLVM IR as for normal code. After that the magic of
> debuggers takes over.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev