Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: [unavailable regs/locals, 0/11] Introduction
Date: Tue, 22 Feb 2011 13:28:00 -0000	[thread overview]
Message-ID: <201102221327.22636.pedro@codesourcery.com> (raw)

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


             reply	other threads:[~2011-02-22 13:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-22 13:28 Pedro Alves [this message]
2011-02-22 15:54 ` Pedro Alves
2011-02-23 21:52   ` Mark Kettenis
2011-02-23 22:49     ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201102221327.22636.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox