[unavailable regs/locals, 0/11] Introduction

[unavailable regs/locals, 0/11] Introduction

[Pedro Alves]

This series mainly teaches GDB about unavailable/uncollected
args/locals properly.  Currently, GDB knows about, and handles
gracefuly unavailable globals, but since the registers unavailable-ness
hasn't been glued yet with values and frames, any local whose
location is dependent on an unavailable register will get
either miscomputed, printed as garbage, or throw an error
instead of printing a graceful "<unavailable>".

E.g., I've placed a tracepoint on line 57, and collected
nothing:

56      void *thread_function0(void *arg) {
57          int my_number =  (long) arg;
58          volatile int *myp = (volatile int *) &args[my_number];
59
60          /* Don't run forever.  Run just short of it :)  */
61          while (*myp > 0)
62            {
63              (*myp) ++;
64              usleep (1);  /* Loop increment.  */

(gdb) trace thread_function0 
Tracepoint 2 at 0x400752: file threads.c, line 57.
(gdb) tstart
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
(gdb) tstop
(gdb) tfind
Found trace frame 0, tracepoint 2
#0  thread_function0 (arg=<unavailable>) at threads.c:57
57          register int my_number =  (long) arg;

(gdb) info registers 
rax            0x0      0
rbx            0x0      0
rcx            0x0      0
rdx            0x0      0
rsi            0x0      0
rdi            0x0      0
rbp            0x0      0x0
rsp            0x0      0x0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0x400752 0x400752 <thread_function0+13>
eflags         0x0      [ ]
cs             0x0      0
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) 

Inspecting the traceframe, one can see above
that gdbserver infers the $PC from the tracepoint address,
but all other registers are shown as 0, which is wrong.
We really don't know their value.

If one prints the locals in this case, we'll see
bogus values:

(gdb) info locals 
my_number = 0
myp = <unavailable>

We don't really know my_number's value, so '0'
is wrong and misleading.  Notice:

(gdb) info scope thread_function0 
Scope for thread_function0:
Symbol arg is a variable at frame base reg $rsp offset 8+-56, length 8.
Symbol my_number is a variable in $rbx, length 4.
Symbol myp is a variable at frame base reg $rsp offset 8+-40, length 8.

So not even myp is correct:

(gdb) p $rsp
$2 = (void *) 0x0
(gdb) p &arg
$3 = (void **) 0xffffffffffffffe8

that's 0 + -40.  Obviously not the correct address of
that local.

The series fixes this by glueing register unavailable-ness 
with value unavailable-ness, and then value unavailable-ness
with frame unavailable-ness.  Midway through the series, since
GDB will be able to distinguish a register value zero from
an unavailable register, GDB will start throwing errors
whenever such register values are used in computations.
The second part of the series makes GDB handle that
gracefuly when necessary (particularly, when the PC itself
is unavailable).

Tested on x86_64-linux, native and gdbserver.  No
regressions, and the new tests pass cleanly.

-- 
Pedro Alves

Re: [unavailable regs/locals, 0/11] Introduction

[Pedro Alves]

On Tuesday 22 February 2011 13:27:22, Pedro Alves wrote:
> Tested on x86_64-linux, native and gdbserver.  No
> regressions, and the new tests pass cleanly.

... and it goes without saying:

I'd appreciate comments and extra eyeballs on all of this.
Pending objections, I'd like to commit after a reasonable wait.

Next up, graceful unwind termination when gdb would
need access to uncollected memory/registers to be able to
unwind further.

-- 
Pedro Alves

Re: [unavailable regs/locals, 0/11] Introduction

[Mark Kettenis]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Tue, 22 Feb 2011 13:37:58 +0000
> 
> On Tuesday 22 February 2011 13:27:22, Pedro Alves wrote:
> > Tested on x86_64-linux, native and gdbserver.  No
> > regressions, and the new tests pass cleanly.
> 
> ... and it goes without saying:
> 
> I'd appreciate comments and extra eyeballs on all of this.
> Pending objections, I'd like to commit after a reasonable wait.

Pedro, I haven't looked very closely at the code yet, but I have a few
worries.  The GCC debug information tends to underspecify the saved
registers in the unwind info.  The unwinder code deals with
"unspecified"[1] registers by assuming they have the same value as in the
"inner" frame.  How does your new code treat such "unspecified"
registers?

[1] "unspecified" is different from "undefined"

Re: [unavailable regs/locals, 0/11] Introduction

[Pedro Alves]

On Wednesday 23 February 2011 21:42:59, Mark Kettenis wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Tue, 22 Feb 2011 13:37:58 +0000
> > 
> > On Tuesday 22 February 2011 13:27:22, Pedro Alves wrote:
> > > Tested on x86_64-linux, native and gdbserver.  No
> > > regressions, and the new tests pass cleanly.
> > 
> > ... and it goes without saying:
> > 
> > I'd appreciate comments and extra eyeballs on all of this.
> > Pending objections, I'd like to commit after a reasonable wait.
> 
> Pedro, I haven't looked very closely at the code yet, but I have a few
> worries.  The GCC debug information tends to underspecify the saved
> registers in the unwind info.  The unwinder code deals with
> "unspecified"[1] registers by assuming they have the same value as in the
> "inner" frame.  How does your new code treat such "unspecified"
> registers?
> 
> [1] "unspecified" is different from "undefined"

My changes related to unavailable register values,
as in their register/memory 's contents not having
been collected by a given tracepoint/traceframe.  This
is ortogonal from unspecified/undefined in debug info.
There's sort of a run-time vs compile-time distinction.
The unavailable-less I've been talking about is of
the run-time kind.  unspecified/undefined is of the
compile-time kind.
If the unwinder assumes an unspecified register has the
same value as in the inner frame, it will continue to do so.
Only when the register value is actually read from the
stack or the register cache, is it determined to be
unavailable/uncollected, and the struct value marked
accordingly.  In the unspecified case, if the register
value is available in the next frame (because enough stack
has been collected to cover the next frame, say), it'll
be available in the this frame too.  If it's unavailable
in the next frame (because not enough stack had been
collected to cover that particular register, that was
saved last in the stack, say), it'll be unavailable
in the this frame too.  (If anything tries to get
at an unavailable value's contents, and exception is
thrown.)

-- 
Pedro Alves