Re: tracepoint bytecode question

["Ke Wang" <ke at alum dot bu dot edu>]

Hi,

I am not the original poster. Sorry if it was confusing for me to use
someone else's post. I am finding the same problem and didn't see any
follow ups to the poster's question so I thought of bringing up the
issue again.

I don't have a code fragment from the target that can be isolated and
reproduced in a computer (the stub is hopelessly meshed with the rest
of the code).

In the target there is this function called int handle_request(char
*request) which handles the maintenance packets gdb sends and whose
first instruction after the prologue starts at 0x16db57c. I want to
trace the request argument. So I use collect $args.

The output from the host side is, with verbose to 1:

(gdb)tstart
LOC_LOCAL request: Collect 4 bytes at offset 00000008 from frame ptr reg 4
(4,00000008,4)
collect register 4
collect register 5

Collecting registers (mask): 0x30
Collecting memranges:
(4, 00000008, 4)

sent 1 tracepoints to target
(gdb)maint packet m16db57c,1
sending: "m16db57c,1"
received: "cc"
(gdb)tfind
(gdb)tdump
Data collected at tracepoint 1, trace frame 0:
(gdb)info args
request = Cannot access memory at address 0x29ff7bc
(gdb)info registers
eax            0xffffffff       -1
ecx            0x6      6
edx            0x0      0
ebx            0x0      0
esp            0x29ff69c        0x29ff69c
ebp            0x29ff7b4        0x29ff7b4
esi            0x0      0
edi            0x0      0
eip            0x16db57c        0x16db57c
eflags         0x0      0
cs             0x0      0
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

If I include:

set_gdbarch_deprecated_fp_regnum(gdbarch, I386_EBP_REGNUM);

in i386-tdep.c, function i386_gdbarch_init, and repeat the steps above, I get:

(gdb)tstart
LOC_LOCAL request: Collect 4 bytes at offset 00000008 from frame ptr reg 5
(5,00000008,4)
collect register 5

Collecting registers (mask): 0x20
Collecting memranges:
(5, 00000008, 4)

sent 1 tracepoints to target
(gdb)maint packet m16db57c,1
sending: "m16db57c,1"
received: "cc"
(gdb)tfind
(gdb)tdump
Data collected at tracepoint 1, trace frame 0:
(gdb)info args
request = 0xe737482 ""
(gdb)info registers
eax            0xffffffff       -1
ecx            0x6      6
edx            0x0      0
ebx            0x0      0
esp            0x0      0x0
ebp            0x29ff7b4        0x29ff7b4
esi            0x0      0
edi            0x0      0
eip            0x16db57c        0x16db57c
eflags         0x0      0
cs             0x0      0
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

"info args" tried looking for the variable location at offset 8 of ebp
(reg 5), but without the deprecated_fp_regnum set, the bytecode
generator was tracing offset 8 of esp (reg 4).

I am not posting it here because set verbose 1 doesn't show much more
information, but when I write: collect request (instead of collect
$args), the functions that get called to generate the bytecode from
ax-gdb.c are:

gen_var_ref
gen_frame_args_address

So "request" is of type LOC_ARG or LOC_REF_ARG according to gdb.

When gen_frame_args_address is called, it invokes
TARGET_VIRTUAL_FRAME_POINTER, which invokes the function pointed by
current_gdbarch->virtual_frame_pointer, which was initialized to
legacy_virtual_frame_pointer function in gdbarch.c and left untouched
by i386_gdbarch_init.

Since i386_gdbarch_init initializes the sp_regnum,
legacy_virtual_frame_pointer returns %esp.

Sorry if this is not reproducible. Any help or suggestion on the
course of action is appreciated.

Thanks,
Ke


On 9/26/06, Jim Blandy <jimb@codesourcery.com> wrote:
> "Ke Wang" <ke@alum.bu.edu> writes:
> > I was just wondering if there was any follow-up to the problem
> > mentioned below?
>
> In my reply to your original message, I asked several questions; I
> can't find answers to them in the mailing list archive.  Did you
> answer them?
>
> In general, a bug report should include all the information I need to
> reproduce the bug myself.  If I can make a bug happen reliably on my
> own machine with a GDB compiled from source, then I can almost
> certainly fix the bug.  If I can't do that, then I almost certainly
> can't fix the bug.
>
> Here were my questions and suggestions:
>
> > If you've come across a variable whose location is being compiled to
> > bytecode incorrectly, please let us know and post what you've found.
> >
> > It's okay if you don't have a patch; it's valuable just to have an
> > example we can work from.
> >
> > If you can, you should try working with GDB 6.4.