Re: breakpoint instruction isn't shown in disassemble or examine (x) commands?

Re: breakpoint instruction isn't shown in disassemble or examine (x) commands?

[Jim Ingham]

"debug target" should show you all the reads & writes to a simulator.  
If you are connecting to the target with gdb's remote protocol, you can 
also use

(gdb) set debug remote on

to watch the gdb remote protocol communications.

Do:

(gdb) help set debug

to see what sorts of debugging options are available for your gdb.

Jim

On Sep 30, 2004, at 10:42 AM, Xinan Tang wrote:

> Hi
>
>   If an ISA simulator is used, how could we do the same way as to the 
> remote target in order to keep track of communication between GDB and 
> the inferior ISA?
>
> Thanks
>
> --Xinan
>
>
> -----Original Message-----
> From: gdb-owner@sources.redhat.com on behalf of Jim Ingham
> Sent: Thu 9/30/2004 10:30 AM
> To: gdb@sources.redhat.com
> Subject: Re: breakpoint instruction isn't shown in disassemble or 
> examine (x) commands?
>
> gdb will always hide the breakpoint trap from you, and show you the
> instruction that is actually going to be run when you get to that pc
> instead.  This is on purpose, it would be very confusing, and not at
> all helpful, for folks to see trap instructions showing up in their
> disassembly.
>
> Is there some reason, other than curiosity, the leads you to want to
> see the trap there?
>
> If you are just curious, try running gdb with:
>
> (gdb) set debug target 1
>
> You can see gdb copy out the actual instruction and lay down the traps,
> and lots of other things you may or may not want to know about...
>
> Jim
>
> On Sep 29, 2004, at 11:36 PM, gdb-digest-help@sources.redhat.com wrote:
>
> >
> >
> > Hi,
> >
> > I am trying to understand the inner workings of a debugger and I 
> found
> > a gdb behaviour that puzzles me.
> >
> > I understand that if I set a software breakpoint (as opposed to
> > an hw breakpoint), gdb will insert an architecture-dependent
> > instruction
> > in the .text section that will cause an exception, that will be 
> handled
> > by gdb.
> >
> > I am using gdb 6.1.1 on FreeBSD i386, so looking at the gdb source,
> > the i386 has the breakpoint instruction 0xcc.
> >
> > I tought of doing something like (in various incantations):
> >
> > (gdb) disassemble foo
> > (gdb) break foo
> > (gdb) disassemble foo
> >
> > and was expecting of seeing the 0xcc instruction in the output of
> > the second disassemble command; instead the output is the same
> > as the first disassemble. Same results with the x command.
> > It seems that gdb wants to "protect" me from seing that the 
> executable
> > is changed?
> >
> > Finally I came up with a function that scans the .text section of
> > the same program (a sort of very naive debugger detector)
> > and hex dumps it. I ran the same program with and without
> > breakpoint and my scan function works as expected: when the 
> breakpoint
> > is
> > set I see it in the hex dump.
> >
> > So somehow I have my sanity back, but the question remains: how
> > can I see the breakpoint instruction from gdb itself?
> >
> > thanks
> > marco
> > --
> > panic("The moon has moved again.");
> >
>
>
>

Re: breakpoint instruction isn't shown in disassemble or examine (x) commands?

[Jim Ingham]

gdb will always hide the breakpoint trap from you, and show you the 
instruction that is actually going to be run when you get to that pc 
instead.  This is on purpose, it would be very confusing, and not at 
all helpful, for folks to see trap instructions showing up in their 
disassembly.

Is there some reason, other than curiosity, the leads you to want to 
see the trap there?

If you are just curious, try running gdb with:

(gdb) set debug target 1

You can see gdb copy out the actual instruction and lay down the traps, 
and lots of other things you may or may not want to know about...

Jim

On Sep 29, 2004, at 11:36 PM, gdb-digest-help@sources.redhat.com wrote:

>
>
> Hi,
>
> I am trying to understand the inner workings of a debugger and I found
> a gdb behaviour that puzzles me.
>
> I understand that if I set a software breakpoint (as opposed to
> an hw breakpoint), gdb will insert an architecture-dependent 
> instruction
> in the .text section that will cause an exception, that will be handled
> by gdb.
>
> I am using gdb 6.1.1 on FreeBSD i386, so looking at the gdb source,
> the i386 has the breakpoint instruction 0xcc.
>
> I tought of doing something like (in various incantations):
>
> (gdb) disassemble foo
> (gdb) break foo
> (gdb) disassemble foo
>
> and was expecting of seeing the 0xcc instruction in the output of
> the second disassemble command; instead the output is the same
> as the first disassemble. Same results with the x command.
> It seems that gdb wants to "protect" me from seing that the executable
> is changed?
>
> Finally I came up with a function that scans the .text section of
> the same program (a sort of very naive debugger detector)
> and hex dumps it. I ran the same program with and without
> breakpoint and my scan function works as expected: when the breakpoint 
> is
> set I see it in the hex dump.
>
> So somehow I have my sanity back, but the question remains: how
> can I see the breakpoint instruction from gdb itself?
>
> thanks
> marco
> -- 
> panic("The moon has moved again.");
>

Re: breakpoint instruction isn't shown in disassemble or examine (x) commands?

[Marco Molteni]

On Thu, 30 Sep 2004 Jim Ingham <jingham@apple.com> wrote:

> gdb will always hide the breakpoint trap from you, and show you the 
> instruction that is actually going to be run when you get to that pc 
> instead.  This is on purpose, it would be very confusing, and not at 
> all helpful, for folks to see trap instructions showing up in their 
> disassembly.
> 
> Is there some reason, other than curiosity, the leads you to want to 
> see the trap there?

No, just curiosity and looking for confirmation of what I am doing ;-)

> If you are just curious, try running gdb with:
> 
> (gdb) set debug target 1
> 
> You can see gdb copy out the actual instruction and lay down the
> traps, and lots of other things you may or may not want to know
> about...

that is what I was looking for I think. Thanks.

marco

breakpoint instruction isn't shown in disassemble or examine (x) commands?

[Marco Molteni]

Hi,

I am trying to understand the inner workings of a debugger and I found
a gdb behaviour that puzzles me.

I understand that if I set a software breakpoint (as opposed to
an hw breakpoint), gdb will insert an architecture-dependent instruction
in the .text section that will cause an exception, that will be handled
by gdb.

I am using gdb 6.1.1 on FreeBSD i386, so looking at the gdb source,
the i386 has the breakpoint instruction 0xcc.

I tought of doing something like (in various incantations):

(gdb) disassemble foo
(gdb) break foo
(gdb) disassemble foo

and was expecting of seeing the 0xcc instruction in the output of
the second disassemble command; instead the output is the same
as the first disassemble. Same results with the x command.
It seems that gdb wants to "protect" me from seing that the executable
is changed?

Finally I came up with a function that scans the .text section of
the same program (a sort of very naive debugger detector)
and hex dumps it. I ran the same program with and without
breakpoint and my scan function works as expected: when the breakpoint is
set I see it in the hex dump.

So somehow I have my sanity back, but the question remains: how
can I see the breakpoint instruction from gdb itself?

thanks
marco
-- 
panic("The moon has moved again.");

Re: breakpoint instruction isn't shown in disassemble or examine (x) commands?

[Eli Zaretskii]

> Date: Thu, 30 Sep 2004 01:03:35 +0200
> From: Marco Molteni <molter@tin.it>
> 
> I tought of doing something like (in various incantations):
> 
> (gdb) disassemble foo
> (gdb) break foo
> (gdb) disassemble foo
> 
> and was expecting of seeing the 0xcc instruction in the output of
> the second disassemble command; instead the output is the same
> as the first disassemble. Same results with the x command.
> It seems that gdb wants to "protect" me from seing that the executable
> is changed?

This is because GDB actually inserts the breakpoint instructions only
when it is about to run the inferior program.  That is, when you type
"break foo", GDB only records that a breakpoint is to be set at the
entry to `foo'; the breakpoint instruction is written there only when
you type "run" or "continue" or some other command that runs the
inferior.  When the inferior stops for any reason, the breakpoint
instruction is removed before GDB returns to the prompt.

> So somehow I have my sanity back, but the question remains: how
> can I see the breakpoint instruction from gdb itself?

Why do you need that?  You already know what you will see there,
right?

Re: breakpoint instruction isn't shown in disassemble or examine (x) commands?

[Marco Molteni]

On Thu, 30 Sep 2004 "Eli Zaretskii" <eliz@gnu.org> wrote:

[..]

> This is because GDB actually inserts the breakpoint instructions only
> when it is about to run the inferior program.  That is, when you type
> "break foo", GDB only records that a breakpoint is to be set at the
> entry to `foo'; the breakpoint instruction is written there only when
> you type "run" or "continue" or some other command that runs the
> inferior.  When the inferior stops for any reason, the breakpoint
> instruction is removed before GDB returns to the prompt.

so I guess that the inferior is run also by the "call" command:

=====================
$ gdb -q stack
(gdb) b f2
Breakpoint 1 at 0x8048532: file stack.c, line 10.
(gdb) b main
Breakpoint 2 at 0x80485d0: file stack.c, line 44.
(gdb) r
Starting program: /home/molter/src/stack 

Breakpoint 2, main () at stack.c:44
44          int b = 78;
(gdb) call check()

*** Found breakpoint instruction at 0x8048532: 0xcc
(gdb)
=====================

where check() looks for the 0xcc byte in the code for f2().

> > So somehow I have my sanity back, but the question remains: how
> > can I see the breakpoint instruction from gdb itself?
> 
> Why do you need that?  You already know what you will see there,
> right?

I "needed" that because I am learning ;-)

thanks, your response confirms that I understood correctly.

marco
-- 
panic("The moon has moved again.");