Live data from Hacker News

How to read variables optimized out in GDB?

luajit.io

11–20 of 24 posts

Re: How to read variables optimized out in GDB?

#11
post #7

This isn't something limited to GDB but I've always wondered why no one seems to have bothered to come up with a solution after all these years so that it can actually know that the variable is in a register at that point.

"Optimized out" doesn't just cover a variable simply being in a register. The code might have been adjusted such that the variable's value isn't stored anywhere any more, or some derivative value is stored instead. So in the general case, it's quite a complex problem.

So in the general case, it's quite a complex problem.

I'm not talking about "the general case". I'm referring to all the cases where the compiler obviously should know where the value is, yet the debugger somehow doesn't.

Re: How to read variables optimized out in GDB?

#12
I got great mileage out of:

-fno-eliminate-unused-debug-symbols

-fno-eliminate-unused-debug-types

https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

this post seems way more hardcore and beyond my experience though.

Re: How to read variables optimized out in GDB?

#13
post #7

This isn't something limited to GDB but I've always wondered why no one seems to have bothered to come up with a solution after all these years so that it can actually know that the variable is in a register at that point.

"Optimized out" doesn't just cover a variable simply being in a register. The code might have been adjusted such that the variable's value isn't stored anywhere any more, or some derivative value is stored instead. So in the general case, it's quite a complex problem.

[deleted]

Re: How to read variables optimized out in GDB?

#14
post #8
post #6

Earlier quoted context omitted.

Having spent some time looking at DWARF data closely, I get the impression that there is an insane amount of information generated and the format can handle way way more complex scenarios than a simple "X is in register Y" - they got a full state machine and all in there. But the tools available.. simply do not consume it? I'm not entirely sure what the disconnect is.

I guess the problem is that variable is in the register only in the beginning of the function. It might overwritten later, that's why the author checks the assembly code. I haven't looked at DWARF for ages. Can it describe the situation that a variable is valid (in some register) in the beginning of a function, but then goes "out of scope " in the middle of the function?

> I haven't looked at DWARF for ages. Can it describe the situation that a variable is valid (in some register) in the beginning of a function, but then goes "out of scope " in the middle of the function?

Yes, with DW_OP_entry_value used in location expressions to indicate that the variable value is in a certain location on entry to the function. However -- debuggers typically don't store all register values on entry to all functions, so usually the stack frame up needs to be instrumented with call site information indicating where the debugger can find longer-term stored copies of the arguments.

In TFA you can see that happening correctly wherever there's a "@entry" annotation from gdb for an argument, in some cases there isn't a longer-term copy of the value further up the stack, in which case the variable remains optimised out.

Re: How to read variables optimized out in GDB?

#15
post #8
post #6

Earlier quoted context omitted.

Having spent some time looking at DWARF data closely, I get the impression that there is an insane amount of information generated and the format can handle way way more complex scenarios than a simple "X is in register Y" - they got a full state machine and all in there. But the tools available.. simply do not consume it? I'm not entirely sure what the disconnect is.

I guess the problem is that variable is in the register only in the beginning of the function. It might overwritten later, that's why the author checks the assembly code. I haven't looked at DWARF for ages. Can it describe the situation that a variable is valid (in some register) in the beginning of a function, but then goes "out of scope " in the middle of the function?

[deleted]

Re: How to read variables optimized out in GDB?

#16
post #7

Earlier quoted context omitted.

"Optimized out" doesn't just cover a variable simply being in a register. The code might have been adjusted such that the variable's value isn't stored anywhere any more, or some derivative value is stored instead. So in the general case, it's quite a complex problem.

So in the general case, it's quite a complex problem. I'm not talking about "the general case". I'm referring to all the cases where the compiler obviously should know where the value is, yet the debugger somehow doesn't.

> I'm referring to all the cases where the compiler obviously should know where the value is, yet the debugger somehow doesn't.

Soooommmee of this can be explained by the design decisions in the compiler not lending themselves to working well with debug-info, as explained here [0] (shamless plug), from about 3 minutes in there's an example of a scenario where a variable location has to be discarded out of conservative precaution (4:40 to 7:00), rather than because it's definitely been optimised out.

[0] https://www.youtube.com/watch?v=yxuwfNnp064&t=45s

Re: How to read variables optimized out in GDB?

#17
post #7

Earlier quoted context omitted.

"Optimized out" doesn't just cover a variable simply being in a register. The code might have been adjusted such that the variable's value isn't stored anywhere any more, or some derivative value is stored instead. So in the general case, it's quite a complex problem.

So in the general case, it's quite a complex problem. I'm not talking about "the general case". I'm referring to all the cases where the compiler obviously should know where the value is, yet the debugger somehow doesn't.

But there are plenty of cases where a debugger can tell you the value of variables which are definitely in registers, such as with function arguments.

So this complaint really is about cases related to the optimizer which, as mentioned, is a very complex issue.

Re: How to read variables optimized out in GDB?

#19

This isn't something limited to GDB but I've always wondered why no one seems to have bothered to come up with a solution after all these years so that it can actually know that the variable is in a register at that point.

There are solutions, but with tradeoffs. In theory DWARF debugging metadata is Turing complete, so you could bundle an exact copy of the unoptimized program and fall back in that when someone requests something from the debugger. The JVM actually exposes this kind of level of access as API and it goes through astonishing amounts of effort to make sure that when you’re debugging the code gets shunted into the paths where this information is available rather than the highly optimized view that is normally executing.

In practice, well, things are complicated. Maintaining sane debug information across optimizations is pretty hard, and nobody really holds compiler author’s feet to the fire to make it happen. There’s a lot of low hanging fruit that should be fixed (for example an index→pointer conversion should be easy to undo, even though most compilers don’t generate the debug information for this). Likewise variables that just happen to be alive by chance should be made available. But I doubt we’ll ever get good support for things which have been fully optimized, though I think most programmers will forgive this.

Re: How to read variables optimized out in GDB?

#20
post #10

This is "How to read variables optimized out in GDB sometimes ", lest you might be misled to think that the value you are looking for is always hanging around somewhere. Sometimes, it's just gone, literally optimized out completely. Consider this piece of code: bool foo(void) { int v = some_system_call(); bool b = v > 500; some_function(b); ... /\* rest of code not using v \*/ } There is no reason for the original va…

The article actually suggests using the record command in that case.
Post reply on HN