gdb refuses to 'break'

gdb refuses to 'break'

[Markus Brandner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Either I missed the point when reading the gdb documentation or
I'm just experiencing some strange behaviour in gdb.
Im running a Slackware 8.1 system on kernel 2.4.18 with
libc-2.2.5

When I compile the following code:

test.c:
#include <stdio.h>

int main(int argc, char **argv)
{
	printf("Breakpoint test\n");
	return 0;
}

using "gcc -g test.c -o test" (my gcc is 2.95.3)
and try to set a break-point with gdb 5.2:

(gdb) break main
Breakpoint 1 at 0x80483f6: file test.c, line 5.
(gdb) run
Starting program: /home/home_PCs105/brandner/tmp/test 
Breakpoint test

Program exited normally.
You can't do that without a process to debug.
(gdb) 

gdb seems to run straight through ignoring the break.
I tried break: line number - same result
I even get the same results using gdb 5.3.

However, compiling the same source using the same gcc
on a libc-2.2.3 machine (kernel 2.2.21) and trying to
do the same thing using gdb 5.0 works perfectly
(but not with any more recent gdb version)

What am I missing?

Thanks for your help,

Markus
- -- 
- -----------------------------------------------------------------
Markus Brandner               Institute of Electrical Measurement
                                and Measurement Signal Processing
phone: +43 316 873 7773             Graz University of Technology
fax:   +43 316 873 4279                     Schiessstattgasse 14B
email: brandner@emt.tugraz.at                 A8010 Graz, Austria
- -----------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+nZ5BjjwO/+h9egkRAtf5AKCPC8DmjWw4L4ktKIMppsMvH+PSmQCglfUw
otygkEI0FAtE7vh6FVvLr4o=
=2tWf
-----END PGP SIGNATURE-----

return type of a fucntion

[Smita]

Hi,
When I print $r3 on returning from a function, I get the return value. But
is there a way to get the type of the return value (eg. whether it is a
pointer or an interger)??

Thanks!
Smita

gdb's communication to a process/libgdb?

[Smita]

Hi,
 I am spawing a gdb process from my process and feeding to gdb an input
script.
I want the parent process to be able to control this gdb process. For this
to happen, I want to communicate to the parent process that a breakpoint
has occurred when gdb stops at a breakpoint? Is it possible to to this?
There is something called libgdb. I am not sure if that can be used for
this purpose.

Any feedback on this would be greatly appreciated.
Thanks
Smita

Re: gdb's communication to a process/libgdb?

[Daniel Jacobowitz]

On Wed, Apr 16, 2003 at 12:59:14PM -0700, Smita wrote:
> Hi,
>  I am spawing a gdb process from my process and feeding to gdb an input
> script.
> I want the parent process to be able to control this gdb process. For this
> to happen, I want to communicate to the parent process that a breakpoint
> has occurred when gdb stops at a breakpoint? Is it possible to to this?
> There is something called libgdb. I am not sure if that can be used for
> this purpose.
> 
> Any feedback on this would be greatly appreciated.

You should probably be reading the documentation for "MI".  Check the
manual, available online under http://sources.redhat.com/gdb/.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

libgdb

[Smita]

Hi,
 I am new to libgdb. Could someone please give me a pointer to its usage
documentaion?
Thanks
Smita

is libgdb okay to use?

[Smita]

Hi,
 I read somewhere that libgdb project was scrapped. Is that true?

Thanks
Smita

Re: libgdb

[Elena Zannoni]

Smita writes:
 > Hi,
 >  I am new to libgdb. Could someone please give me a pointer to its usage
 > documentaion?
 > Thanks
 > Smita
 > 


http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC207

Re: libgdb

[Smita]

Where can I get libgdb from?

Thanks!
Smita

On Wed, 16 Apr 2003, Elena Zannoni wrote:

> Smita writes:
>  > Hi,
>  >  I am new to libgdb. Could someone please give me a pointer to its usage
>  > documentaion?
>  > Thanks
>  > Smita
>  >
>
>
> http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC207
>

finish implementation

[Smita]

Hi,
 How is finish implemented? Is it an internal breakpoint for gdb which is
not visible to user?

Thanks
Smita

Re: libgdb

[Elena Zannoni]

Smita writes:
 > Where can I get libgdb from?
 > 

there is no libgdb entity per se. The Mi interface is included with the
regular gdb sources.

 > Thanks!
 > Smita
 > 
 > On Wed, 16 Apr 2003, Elena Zannoni wrote:
 > 
 > > Smita writes:
 > >  > Hi,
 > >  >  I am new to libgdb. Could someone please give me a pointer to its usage
 > >  > documentaion?
 > >  > Thanks
 > >  > Smita
 > >  >
 > >
 > >
 > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC207
 > >

finish for nested function calls

[Smita]

Hi,
 What is the expected behavior of finish when it is called from multiple
nested funtions?
e.g:
f1() calls f2():
f1()
{
  f2()
}

i do this in gdb:
b f1
finish
end
b f2
finish
end

finish takes effect only for f2() (the innermost function)
So, I get return value from f2() and gdb stops after it returns from f2().
I don't get the return value for f1().
Is that the expected beahvior?

Thanks
Smita

Re: return type of a fucntion

[Peter Barada]

>Hi,
>When I print $r3 on returning from a function, I get the return value. But
>is there a way to get the type of the return value (eg. whether it is a
>pointer or an interger)??

If you know which function you're in, you could always 'ptype
functionName' where 'fuctionName' is replaced with the function's name
and you'll see the type that the function returns. Then you could cast
$r3 to that type.  Of course this doesn't works so well with
float/double as well as structures.

-- 
Peter Barada
peter@baradas.org

Re: gdb refuses to 'break'

[Markus Brandner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 16 April 2003 20:17, you wrote:

[...]

> gdb seems to run straight through ignoring the break.
> I tried break: line number - same result
> I even get the same results using gdb 5.3.

This issue is resolved.
The no-'break' problem was not at all related to gdb :)
I ran the test on different machines - every single on (except
the one with the 2.2.21 kernel) having installed the no-ptrace 
kernel patch!

Markus
- -- 
- -----------------------------------------------------------------
Markus Brandner               Institute of Electrical Measurement
                                and Measurement Signal Processing
phone: +43 316 873 7773             Graz University of Technology
fax:   +43 316 873 4279                     Schiessstattgasse 14B
email: brandner@emt.tugraz.at                 A8010 Graz, Austria
- -----------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+nnAQjjwO/+h9egkRAnduAJ9WBCTFODlmqFXyuvAo5zu3cVV2RACfUgdy
+eCEg9lDk1yy/af1g34I4/M=
=oMRO
-----END PGP SIGNATURE-----

libgdb

[Matthew Hall]

I've seen references to a libgdb project.
Can anyone tell me if libgdb is still active?
Is it complete?
Is it used internally by gdb itself?

Thanks for any info or links to useful documentation.

Re: libgdb

[Daniel Jacobowitz]

On Fri, Nov 02, 2007 at 04:45:45PM +0000, Matthew Hall wrote:
> I've seen references to a libgdb project.
> Can anyone tell me if libgdb is still active?

No.

> Is it complete?

No.

> Is it used internally by gdb itself?

No clear answer to this.  There was a "libgdb interface"; some bits of
GDB use it, other bits do not.  It's all linked in together.

-- 
Daniel Jacobowitz
CodeSourcery

Re: libgdb

[Stan Shebs]

Matthew Hall wrote:
> I've seen references to a libgdb project.
>   
An idea left over from ancient days, never got off the ground. The 
theory was that one could link it into both the traditional command-line 
frontend and into various GUIs. Lots of technical difficulties, two 
chief ones being that 1) it would have had to be a very "wide" API in 
order to be sufficient to cover all of GDB functionality, and 2) the 
library would have to be able to hand control back to the UI on demand, 
difficult when inferior control uses blocking system calls. In practice, 
it seems to work well enough to have the GUI be a separate program that 
communicates with GDB, whether via command line or MI (machine 
interface) syntax, and there is some advantage to the "firewalling" 
inherent in a two-program scheme, so there's not much motivation to do a 
libgdb anymore.

Stan

Frame handling

[Jafa]

Hi all,

I am bringing the ip2k port back in sync with the trunk and I need to check
my (limited) understanding of the new scheme...

This email is mostly a ramble about my understanding of the new frame
handling that I would like a sanity check on.

frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
function handlers:
this_base - given a frame, figure out the base address of the caller frame
(caller's FP)... usually this means doing some analysis to figure everything
out about the frame and populating the port-specific cache for this new
frame.
this_locals - given a frame, figure out the address of the local variables
of the callers frame (usually caller's FP as debug info already allows for
the offset).
this_args - given a frame, figure out the address of the args passed to the
callers frame (usually caller's FP as debug info already allows for the
offset).

Port specific implementation... The first time one of these functions is
called the port-specific cache will be a NULL pointer... the code should
allocate memory to hold the useful frame variables and figure out the frame
information. Subsequent calls will receive the cache back and can return the
values from the cache.

frame_base_set_default also sets the unwind options...
type - always NORMAL_FRAME?
this_id - Given a frame, return a unique identifier for the caller's frame
based on the caller's frame base address and the calling functions entry
point.
prev_register - Given a frame, return the value of a specified register as
it was on entry to this function (registers that are known to be saved on
the stack)

Question - what registers is gdb expecting prev_register to give reasonable
results for? Just PC? Or SP and FP as well?

Question - reading through this again I think the goal of call these
functions is to work with the current frame and the function get passed the
child frame so they can do a backtrace if it hasn't already been done... why
not call a function to do a 1 level backtrace and then eliminate the
next_frame parameter? It would recduce confusion and most ports will have an
internal unwind function anyway.

frame_unwind_append_predicate (gdbarch, d10v_frame_p) - this seams to
register the same unwind options as above?

I think this makes sense but I would appreciate a sanity check :-)

Thanks

Nick

Nick Kelsey
Senior Software Engineer
Ubicom

Re: Frame handling

[Daniel Jacobowitz]

On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote:
> Hi all,
> 
> I am bringing the ip2k port back in sync with the trunk and I need to check
> my (limited) understanding of the new scheme...
> 
> This email is mostly a ramble about my understanding of the new frame
> handling that I would like a sanity check on.
> 
> frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
> function handlers:
> this_base - given a frame, figure out the base address of the caller frame
> (caller's FP)... usually this means doing some analysis to figure everything
> out about the frame and populating the port-specific cache for this new
> frame.
> this_locals - given a frame, figure out the address of the local variables
> of the callers frame (usually caller's FP as debug info already allows for
> the offset).
> this_args - given a frame, figure out the address of the args passed to the
> callers frame (usually caller's FP as debug info already allows for the
> offset).
> 
> Port specific implementation... The first time one of these functions is
> called the port-specific cache will be a NULL pointer... the code should
> allocate memory to hold the useful frame variables and figure out the frame
> information. Subsequent calls will receive the cache back and can return the
> values from the cache.

You're good so far.

> frame_base_set_default also sets the unwind options...

No, it doesn't.  That unwind member is used for comparison purposes
only.  See the "Sneaky" comment in get_frame_base_address, and all of
"frame-unwind.h".  Esp. frame_unwind_append_predicate.

> type - always NORMAL_FRAME?

For a target's unwinders, probably.

> this_id - Given a frame, return a unique identifier for the caller's frame
> based on the caller's frame base address and the calling functions entry
> point.
> prev_register - Given a frame, return the value of a specified register as
> it was on entry to this function (registers that are known to be saved on
> the stack)
> 
> Question - what registers is gdb expecting prev_register to give reasonable
> results for? Just PC? Or SP and FP as well?

As many as possible.  This _completely_ replaces all other unwinding,
for instance frame_chain and the extra_info/saved_registers data. 
Might want to take a look at the ARM conversion I just posted; I don't
promise it's right...

> Question - reading through this again I think the goal of call these
> functions is to work with the current frame and the function get passed the
> child frame so they can do a backtrace if it hasn't already been done... why
> not call a function to do a 1 level backtrace and then eliminate the
> next_frame parameter? It would recduce confusion and most ports will have an
> internal unwind function anyway.

Because it doesn't make much difference, I think.  The key is that the
info generated when doing the backtrace is target specific, and opaque.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Jafa]

Hi Andrew,

>>> Question - what registers is gdb expecting prev_register to give
reasonable
>>> results for? Just PC? Or SP and FP as well?
>>
>> As many as possible.  This _completely_ replaces all other unwinding,
>> for instance frame_chain and the extra_info/saved_registers data.
>> Might want to take a look at the ARM conversion I just posted; I don't
>> promise it's right...
>
>Yes.  GDB now relies on the prev_register method when popping a frame so
>unless it works well, things fail pretty quick.

Ok

The ABI states that everything is callee clobbered so the only things I can
recover will be the PC, SP, and FP. There is no FP register so FP and SP are
search-calculated.

I will clean up the ip3k (aka ip4k) frame_handling next so should be able to
recover the saved address registers (all data registers are callee
clobbered).

BTW - Sorry I missed the branch, management didn't pay any attention to my
recomendation 3 weeks ago... and *now* they decide we need to fix gdb and
merge up to the trunk :-)

Thanks

Nick

Re: Frame handling

[Andrew Cagney]

>>>> Question - reading through this again I think the goal of call these
>>>> functions is to work with the current frame and the function get passed the
>>>> child frame so they can do a backtrace if it hasn't already been done... why
>>>> not call a function to do a 1 level backtrace and then eliminate the
>>>> next_frame parameter? It would recduce confusion and most ports will have an
>>>> internal unwind function anyway.
> 
> 
>> 
>>> Question - reading through this again I think the goal of call these
>>> functions is to work with the current frame and the function get passed the
>>> child frame so they can do a backtrace if it hasn't already been done... why
>>> not call a function to do a 1 level backtrace and then eliminate the
>>> next_frame parameter? It would recduce confusion and most ports will have an
>>> internal unwind function anyway.
> 
>> 
>> I'm not sure I understand the question.

> I agree, and I don't think it will make much difference eitehr way, however
> I was just thinking that it would be a whole lot easier to explain these
> functions...
> 

Um, this is still dangling.  Can you please express your question using 
terminology consistent with the frame unwind code.

Andrew

Re: Frame handling

[Daniel Jacobowitz]

On Tue, Jul 01, 2003 at 08:58:46AM -0400, Andrew Cagney wrote:
> >>>>Question - reading through this again I think the goal of call these
> >>>>functions is to work with the current frame and the function get passed 
> >>>>the
> >>>>child frame so they can do a backtrace if it hasn't already been 
> >>>>done... why
> >>>>not call a function to do a 1 level backtrace and then eliminate the
> >>>>next_frame parameter? It would recduce confusion and most ports will 
> >>>>have an
> >>>>internal unwind function anyway.
> >
> >
> >>
> >>>Question - reading through this again I think the goal of call these
> >>>functions is to work with the current frame and the function get passed 
> >>>the
> >>>child frame so they can do a backtrace if it hasn't already been done... 
> >>>why
> >>>not call a function to do a 1 level backtrace and then eliminate the
> >>>next_frame parameter? It would recduce confusion and most ports will 
> >>>have an
> >>>internal unwind function anyway.
> >
> >>
> >>I'm not sure I understand the question.
> 
> >I agree, and I don't think it will make much difference eitehr way, however
> >I was just thinking that it would be a whole lot easier to explain these
> >functions...
> >
> 
> Um, this is still dangling.  Can you please express your question using 
> terminology consistent with the frame unwind code.

I think Nick's question is: why does every architecture implement the
cache lazily, instead of GDB instructing the architecture when to
create the cache.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Jafa]

Hi Andrew,

>The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed.
>General confusion over what was ment to happen when quickly exploded
>into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC,
>INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to
>initialize the cache[s] (there ended up being three!) but many, such as
>FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they
>didn't even have access to the cache).

Yeah, that was a bit of a mess :-)

>The new code takes the oposite approach.  Only specify interfaces that
>are absolutly needed and make the unwinder 100% responsible for all
>cache management, populating it based on the immediate demand.
>
>One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing
>prologue analysis).  It may be possible to implement this in the new
>unwinders - id_unwind would only create/populate what was immediatly
>necessary and avoid a full prologue analysis (something that is
>considered expensive).

Makes sense.... the trick is to leave this power to the port-specific code.

The proposal in my last email still allows the port-writer to implement a
light-weight frame_chain but I have to admit that it doesn't point them in
that direction.

Thanks for your time BTW - My view of the world is pretty small.

Nick

libgdb

[jacques]

Hello,
I'm currently working on a new debugger, and I want to base it on 
libgdb. However, finding documentation about libgdb, or even finding 
libgdb itself, has proved a daunting task. My understanding is that 
libgdb is simply a library containing all the high level functions of 
gdb, but let's me call them inside my code. Is libgdb rebuilt everytime 
a new gdb comes out? where can i find more information about 
libgdb(google gives me 2 manuals, both very very sparse on any 
information), and where would I get the latest libgdb?
--Jacques

libgdb

[a2782]

Hi to all!

I am involved in a project of making a educational graphic interface 
and we are thinking about putting it over GDB. My question is: Has 
anybody worked with libgdb? My first approximation is invoking gdb as 
Emacs does, but using libgdb. I hope someone has worked with libgdb and 
can help and advise me.

Thanks in advance!

Re: libgdb

[Keith Seitz]

On Fri, 22 Nov 2002 a2782@dis.ulpgc.es wrote:

> I am involved in a project of making a educational graphic interface 
> and we are thinking about putting it over GDB. My question is: Has 
> anybody worked with libgdb? My first approximation is invoking gdb as 
> Emacs does, but using libgdb. I hope someone has worked with libgdb and 
> can help and advise me.

Sadly, libgdb is a pipedream, and still quite a ways off (but it's 
getting closer almost every day).

There are three ways to commonly interface some sort of GUI application 
top of GDB:

1) Invoke GDB and parse the command line (emacs does this)
2) Invoke GDB's MI interpreter and write yourself an MI parser (Eclipse 
and Apple's tools for MacOS X do this)
3) Write your GUI using GDB's hooks and events (Insight does this)

Obviously, #2 is the most desirably way to isolate yourselves from GDB 
changes. Unfortunately, MI is still a work in progress. (Of course, I'm 
still partial to #3 for speed.. ;-)

Keith

Re: libgdb

[Joel Brobecker]

> 1) Invoke GDB and parse the command line (emacs does this)
> 2) Invoke GDB's MI interpreter and write yourself an MI parser (Eclipse 
> and Apple's tools for MacOS X do this)
> 3) Write your GUI using GDB's hooks and events (Insight does this)
> 
> Obviously, #2 is the most desirably way to isolate yourselves from GDB 
> changes. Unfortunately, MI is still a work in progress. (Of course, I'm 
> still partial to #3 for speed.. ;-)

One advantage of method #1 or #2, used by GVD, is that GDB is a separate
process. This GDB process does not need to run on the same host as GVD.
Even if I'm debugging on a distant machine, I can run GVD on my local
machine, reducing tremendously the network traffic. Given that I live in
the west coast, and that most machines I work on are located in NY and
Paris, this is a definite plus.

I think GVD uses method #1, but I would recommend method #2 as the
output is most probably easier to parse.

-- 
Joel

libgdb

[Satya]

Hi,
  I am new to libgdb.Can some one tell me how I can use libgdb to
construct an object containing the result of the gdb command.

Thanks,
Satya