How to read variables optimized out in GDB?

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.

Re: How to read variables optimized out in GDB?

#6

Post by stefan_ » Tue, Oct 11, 2022, 10:48 PM UTC

userbinator wrote: post #5

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.

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.

Re: How to read variables optimized out in GDB?

#7

Post by rlpb » Tue, Oct 11, 2022, 11:06 PM UTC

userbinator wrote: post #5

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.

Re: How to read variables optimized out in GDB?

#8

Post by usr1106 » Tue, Oct 11, 2022, 11:13 PM UTC

stefan_ wrote: post #6

userbinator wrote: post #5

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.

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?

Re: How to read variables optimized out in GDB?

#9

Post by jmorse2 » Tue, Oct 11, 2022, 11:19 PM UTC

userbinator wrote: post #5

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.

Assuming you're referring to the articles first example, I suspect optimised-out is the correct outcome in that situation. The program is stopped at the start of one function, and the author is looking one stack frame up at this code:

     0x0000564ab5d178c4 :    callq  *%rax
  => 0x0000564ab5d178c6 :    mov    %rbp,%rdi

%rsi indeed hasn't been clobbered when the call executes, but it becomes liable to be clobbered during the execution of the callee. By the next instruction (at +54) there's no guarantee that %rsi contains the correct value, thus it's best reported as optimised out. The author is handily stopped at a point in time between the two instructions displayed above (in a lower stack frame), where the correct value happens to be in %rsi, but this is not guaranteed to be always true.

Re: How to read variables optimized out in GDB?

#10

Post by anyfoo » Tue, Oct 11, 2022, 11:25 PM UTC

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 value of v to stick around any longer than until the comparison with 500 has been made.

Even though the syntactic scope of "int v" tells you that v is valid for the rest of the function body, and indeed it is while you are writing the source code, an optimizing compiler can and should make use of the fact that you are not actually using it anymore.