tracepoint bytecode question

Hi

I was just wondering if there was any follow-up to the
problem
mentioned below?

I am using gdb to trace a remote target (i386). After
i386_gdbarch_init
in i386-tdep is called, gdbarch->virtual_frame_pointer is
still

pointing at legacy_virtual_frame_pointer (in arch-utils.c)
function call.

What is the "correct" way of initializing the
virtual_frame_pointer field
in i386_gdbarch_init?

The problem is that since DEPRECATED_FP_REGNUM is not
initialized,

legacy_virtual_frame_pointer returns SP_REGNUM (%esp, reg
4). This is
called by gen_frame_args_address (ax-gdb.c), when I collect
a function
argument, but the argument in my case should be with respect
to %ebp

(reg 5). Am I missing anything?

Thanks for the help.
Ke

=========================================

Der Herr Hofrat <der.herrhofr.at> writes:
>  after writing up tracepoints in a minimum version that
actually kind of

>  works (gdb-6.3) I noticed that there seems to be a lot
of problems with
>  the actual bytecode generated. simple things like
>
>  collect $reg
>  collect variable_name
>
>  work ok, if it gets any more complicated the bytecode
seems to be wrong

>
>  i.e.
>
>  collect x->y
>  collect var1 + var2
>
>  will produce wrong offsets and thus garbage traces,
same thing if compiled
>  with optimization...
>
>  so what I would like to know is how I can figure out
what the bytecode

>  should look like of if it is correct and its my
interpreter that is scewing
>  up - is there any more detailed document on the way
bytecode gets calculated
>  or am I down to "read the source" -
calculating the X packet output on paper

>  the addresses that are finally recorded seem to be
wrong. scaning the path
>  I found the following in the source - which may be
someone could
>  explain ?

Well, you can have GDB print the bytecode for any expression
with the

'maint agent' command.  The definition of the bytecode
language is in
Appendix E of the GDB manual ("The GDB Agent Expression
Mechanism").
'info addr' ought to show you where a variable is located,
but it

currently does not; instead, you can dump DWARF debugging
information
with 'readelf -wi'.

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.



>
> void
> legacy_virtual_frame_pointer (CORE_ADDR pc,

>                               int *frame_regnum,
>                               LONGEST *frame_offset)
> {
>   /* FIXME: cagney/2002-09-13: This code is used when
identifying the
>      frame pointer of the current PC.  It is assuming
that a single

>      register and an offset can determine this.  I
think it should
>      instead generate a byte code expression as that
would work better
>      with things like Dwarf2's CFI.  */
>   if (DEPRECATED_FP_REGNUM >= 0 &&
DEPRECATED_FP_REGNUM < NUM_REGS)

>     *frame_regnum = DEPRECATED_FP_REGNUM;
>   else if (SP_REGNUM >= 0 && SP_REGNUM <
NUM_REGS)
>     *frame_regnum = SP_REGNUM;
>   else
>     /* Should this be an internal error?  I guess so,
it is reflecting

>        an architectural limitation in the current
design.  */
>     internal_error (__FILE__, __LINE__, "No
virtual frame pointer available");
>   *frame_offset = 0;
> }
>
> is the offset really always 0 ??

> Also the register used here is SP_REGNUM (4 on i386)
but it should be 5 ??
>
> The code in question has not really changed in 6.4 - so
this should hold
> for the current gdb - I did not want to move on to a
newer version without

> this woring first.

Hmm.  I'm surprised we're using this at all.  Is GDB really
producing
symbols of type LOC_ARG and LOC_REF_ARG?

"Ke Wang" <kealum.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.

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 <jimbcodesourcery.com> wrote:
>
> "Ke Wang" <kealum.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.
>