"xbreak" command in GDB ?

"xbreak" command in GDB ?

[Sarnath K - CTD, Chennai.]

Hi All,
 The "xbreak" command (and hence "txbreak" ) 
in GDB Version 5.1 doesnt seem to work
properly.
 A minute investigation showed that it is
setting a break-point at a posn
1 past the last instrn of the "function". 
 Looks like a bug. Pardon me if I am wrong.
Maintainers can look into this.

Ciao,
Sarnath

Re: "xbreak" command in GDB ?

[Eli Zaretskii]

> From: "Sarnath K - CTD, Chennai." <k_sarnath@ctd.hcltech.com>
> Date: Thu, 24 Jan 2002 14:59:18 +0530
> 
>  The "xbreak" command (and hence "txbreak" ) 
> in GDB Version 5.1 doesnt seem to work
> properly.

What OS?  What compiler?

On my system (DJGPP, GCC 3.0.2), xbreak does seem to work.

>  A minute investigation showed that it is
> setting a break-point at a posn
> 1 past the last instrn of the "function". 

Could you send a complete short test program and a sequence of
commands, including the compilation command line, to reproduce that?

Re: "xbreak" command in GDB ?

[Pierre Muller]

At 08:45 25/01/2002 , Eli Zaretskii a écrit:
> > From: "Sarnath K - CTD, Chennai." <k_sarnath@ctd.hcltech.com>
> > Date: Thu, 24 Jan 2002 14:59:18 +0530
> > 
> >  The "xbreak" command (and hence "txbreak" ) 
> > in GDB Version 5.1 doesnt seem to work
> > properly.
>
>What OS?  What compiler?
>
>On my system (DJGPP, GCC 3.0.2), xbreak does seem to work.

Well, not the official 5.0 DJGPP release ....
there the position is also after the final ret instruction.

I also tested with cygwin current CVS executable and
it also inserted the breaklpoint past the last instruction.

Anyhow, how is this supposed to work for
C code that can have multiple ret instructions
in one function?

Or is there a compiler switch (for GCC) 
that can force generation of a unique 
exit location?

Otherwise the best solution 
(on systems with hardware watchpoints)
would probably be
to insert a breakpoint at entry
and to watch stackpointer value.


> >  A minute investigation showed that it is
> > setting a break-point at a posn
> > 1 past the last instrn of the "function". 
>
>Could you send a complete short test program and a sequence of
>commands, including the compilation command line, to reproduce that?

Simply try 
./gdb ./gdb
break main
xbreak main
disas main



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: "xbreak" command in GDB ?

[Michael Snyder]

Eli Zaretskii wrote:
> 
> > From: "Sarnath K - CTD, Chennai." <k_sarnath@ctd.hcltech.com>
> > Date: Thu, 24 Jan 2002 14:59:18 +0530
> >
> >  The "xbreak" command (and hence "txbreak" )
> > in GDB Version 5.1 doesnt seem to work
> > properly.
> 
> What OS?  What compiler?

XBREAK was added by HP, in a completely non-portable way, 
and the maintainers did not catch it.  When I can find a
spare moment, I am going to post a patch recommending 
its removal.
 
> On my system (DJGPP, GCC 3.0.2), xbreak does seem to work.

If you look at how XBREAK is implemented, you will see
that if it works at all it is sheer coincidence, and it
doesn't really do anything useful even then.  The best it
may do is stop you at the return instruction, and by then
your stack frame will have been destroyed.

> >  A minute investigation showed that it is
> > setting a break-point at a posn
> > 1 past the last instrn of the "function".
> 
> Could you send a complete short test program and a sequence of
> commands, including the compilation command line, to reproduce that?

Re: "xbreak" command in GDB ?

[Michael Snyder]

"Sarnath K - CTD, Chennai." wrote:
> 
> Hi All,
>  The "xbreak" command (and hence "txbreak" )
> in GDB Version 5.1 doesnt seem to work
> properly.
>  A minute investigation showed that it is
> setting a break-point at a posn
> 1 past the last instrn of the "function".
>  Looks like a bug. Pardon me if I am wrong.
> Maintainers can look into this.

XBREAK is a mistake.  It got in because the maintainers
were not paying close enough attention (it was part of a
really huge merge).  It is completely non-portable, and
there is probably no good way to make it portable.  Nor
does it do anything particularly useful (even if you can
stop at the return instruction of a function, your stack
frame will generally have been destroyed already).

I'm going to propose a patch that will take xbreak out.

Re: "xbreak" command in GDB ?

[Michael Snyder]

Pierre Muller wrote:
> 
> At 08:45 25/01/2002 , Eli Zaretskii a écrit:
> > > From: "Sarnath K - CTD, Chennai." <k_sarnath@ctd.hcltech.com>
> > > Date: Thu, 24 Jan 2002 14:59:18 +0530
> > >
> > >  The "xbreak" command (and hence "txbreak" )
> > > in GDB Version 5.1 doesnt seem to work
> > > properly.
> >
> >What OS?  What compiler?
> >
> >On my system (DJGPP, GCC 3.0.2), xbreak does seem to work.
> 
> Well, not the official 5.0 DJGPP release ....
> there the position is also after the final ret instruction.
> 
> I also tested with cygwin current CVS executable and
> it also inserted the breaklpoint past the last instruction.
> 
> Anyhow, how is this supposed to work for
> C code that can have multiple ret instructions
> in one function?

It can't.


> Or is there a compiler switch (for GCC)
> that can force generation of a unique
> exit location?

No.

> Otherwise the best solution
> (on systems with hardware watchpoints)
> would probably be
> to insert a breakpoint at entry
> and to watch stackpointer value.

> > >  A minute investigation showed that it is
> > > setting a break-point at a posn
> > > 1 past the last instrn of the "function".
> >
> >Could you send a complete short test program and a sequence of
> >commands, including the compilation command line, to reproduce that?
> 
> Simply try
> /gdb ./gdb
> break main
> xbreak main
> disas main
> 
> Pierre Muller
> Institut Charles Sadron
> 6,rue Boussingault
> F 67083 STRASBOURG CEDEX (France)
> mailto:muller@ics.u-strasbg.fr
> Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

RE: "xbreak" command in GDB ?

[Elena Zannoni]

Pierre Muller writes:
 > At 09:29 25/01/2002 , Sarnath K - CTD, Chennai. a écrit:
 > > >Simply try 
 > > >./gdb ./gdb
 > > >break main
 > > >xbreak main
 > > >disas main
 > >
 > >  GDB never exits via the leaving point
 > >of main() function, I suppose.
 > >It exits via "quit_command" function.
 > >I vaguely remember this ( when I was
 > >browsing GDB source code.) So this test
 > >might not reflect things correctly.
 > >Correct me if I am wrong
 > 
 > I didn't want to say that you should run the progream after.
 > Simply comparing the address of the xbreak with
 > the position of the ret instruction
 > in the function disassembly is enough to
 > show that you are right in saying that this
 > command is buggy for i386 at least.
 > 
 > Looking into source it apears that this is 
 > related to function
 > find_pc_sect_partial_function
 > 
 > because xbreak uses the returned endaddr value.
 > 
 > function description says that
 > /* Finds the "function" (text symbol) that is smaller than PC but
 >     greatest of all of the potential text symbols in SECTION.  Sets
 >     *NAME and/or *ADDRESS conditionally if that pointer is non-null.
 >     If ENDADDR is non-null, then set *ENDADDR to be the end of the
 >     function (exclusive), but passing ENDADDR as non-null means that
 >     the function might cause symbols to be read.  This function either
 >     succeeds or fails (not halfway succeeds).  If it succeeds, it sets
 >     *NAME, *ADDRESS, and *ENDADDR to real information and returns 1.
 >     If it fails, it sets *NAME, *ADDRESS, and *ENDADDR to zero and
 >     returns 0.  */
 > 
 > The exclusive attribute should be the reason why this works
 > but the endaddress is simply set by 
 >                cache_pc_function_high = BLOCK_END (SYMBOL_BLOCK_VALUE (f));
 > (cache_pc_function_high is copied into endaddr at function end)
 > 
 > But I don't think  that BLOCK_END should 
 > exclude any instruction, so its probably here that we should 
 > decrement  but there is no code for 
 > function_epilogue in i386-tdep.c 
 > 


Yes, this command was introduced with the infimous HP merge. xbreak
and txbreak never worked as advertized. If you look at the HP sources
(available at the www.hp.com) you'll notice that they added some very
very very platform specific hacks to make the command work.

Similarly for another command 'bx' available in xdb mode only.

None of these commands are documented or tested.

Michael, what should we do? 

Elena


 > 
 > 
 > Pierre Muller
 > Institut Charles Sadron
 > 6,rue Boussingault
 > F 67083 STRASBOURG CEDEX (France)
 > mailto:muller@ics.u-strasbg.fr
 > Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

RE: "xbreak" command in GDB ?

[Pierre Muller]

At 09:29 25/01/2002 , Sarnath K - CTD, Chennai. a écrit:
> >Simply try 
> >./gdb ./gdb
> >break main
> >xbreak main
> >disas main
>
>  GDB never exits via the leaving point
>of main() function, I suppose.
>It exits via "quit_command" function.
>I vaguely remember this ( when I was
>browsing GDB source code.) So this test
>might not reflect things correctly.
>Correct me if I am wrong

I didn't want to say that you should run the progream after.
Simply comparing the address of the xbreak with
the position of the ret instruction
in the function disassembly is enough to
show that you are right in saying that this
command is buggy for i386 at least.

Looking into source it apears that this is 
related to function
find_pc_sect_partial_function

because xbreak uses the returned endaddr value.

function description says that
/* Finds the "function" (text symbol) that is smaller than PC but
    greatest of all of the potential text symbols in SECTION.  Sets
    *NAME and/or *ADDRESS conditionally if that pointer is non-null.
    If ENDADDR is non-null, then set *ENDADDR to be the end of the
    function (exclusive), but passing ENDADDR as non-null means that
    the function might cause symbols to be read.  This function either
    succeeds or fails (not halfway succeeds).  If it succeeds, it sets
    *NAME, *ADDRESS, and *ENDADDR to real information and returns 1.
    If it fails, it sets *NAME, *ADDRESS, and *ENDADDR to zero and
    returns 0.  */

The exclusive attribute should be the reason why this works
but the endaddress is simply set by 
               cache_pc_function_high = BLOCK_END (SYMBOL_BLOCK_VALUE (f));
(cache_pc_function_high is copied into endaddr at function end)

But I don't think  that BLOCK_END should 
exclude any instruction, so its probably here that we should 
decrement  but there is no code for 
function_epilogue in i386-tdep.c 



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

RE: "xbreak" command in GDB ?

[Sarnath K - CTD, Chennai.]

>Simply try 
>./gdb ./gdb
>break main
>xbreak main
>disas main

 GDB never exits via the leaving point
of main() function, I suppose.
It exits via "quit_command" function.
I vaguely remember this ( when I was
browsing GDB source code.) So this test
might not reflect things correctly.
Correct me if I am wrong

Sarnath

RE: "xbreak" command in GDB ?

[Sarnath K - CTD, Chennai.]

Hi,

The following is the session demonstrating
failure of "xbreak" on GDB Version 5.1 (for i386), running
on Linux kernel 2.4.0/Pentium III. GDB was configured
for "i686-pc-linux-gnu".

Source:

[root@boost /tmp]# cat xbreak.c
int main()
{
        a();
}

int a()
{
        int i=0, j=0;

        return 0;
}

Compilation:

[root@boost /tmp]# cc -g -o xbreak xbreak.c

Debug session:

[root@boost /tmp]# ./gdb ./xbreak
GNU gdb 5.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) xbreak a
Breakpoint 1 at 0x80483c6
(gdb) run
Starting program: /tmp/./xbreak

Program exited normally.
(gdb) disassemble a
Dump of assembler code for function a:
0x80483ac <a>:  push   %ebp
0x80483ad <a+1>:        mov    %esp,%ebp
0x80483af <a+3>:        sub    $0x8,%esp
0x80483b2 <a+6>:        movl   $0x0,0xfffffffc(%ebp)
0x80483b9 <a+13>:       movl   $0x0,0xfffffff8(%ebp)
0x80483c0 <a+20>:       xor    %eax,%eax
0x80483c2 <a+22>:       jmp    0x80483c4 <a+24>
0x80483c4 <a+24>:       leave
0x80483c5 <a+25>:       ret
End of assembler dump.

Conclusion:
 The "xbreak" command says that it has set the bkpt at
0x80483c6. But the disassembly says that the last instruction
(ret) is at location 0x80483c5. Is this a bug ?

Thanks,
Sarnath