headers
Eli Zaretskii | 1 May 2009 10:06
Picon

Re: Remote core file debugging

> Date: Thu, 30 Apr 2009 23:37:05 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis <at> xs4all.nl>
> CC: gdb <at> sourceware.org
> 
> > If gdbserver does not support this, what alternatives do I have?
> 
> Copy the core file and binaries to a somewhat more powerful machine
> and use a cross-gdb (the same you'd probably use with gdbserver)?

No, I don't need a cross-gdb, as both systems are Red Hat.

Thanks.
Permalink | Reply | 0 comments |
headers
Marc Khouzam | 1 May 2009 20:39
Picon
Favicon
Gravatar

RE: Does HEAD support non-stop with 'gdbserver --multi' on Linux?


> -----Original Message-----
> From: Pedro Alves [mailto:pedro <at> codesourcery.com] 
> Sent: Thursday, April 30, 2009 5:45 PM
> To: Marc Khouzam
> Cc: gdb <at> sourceware.org
> Subject: Re: Does HEAD support non-stop with 'gdbserver 
> --multi' on Linux?
> 
> On Thursday 30 April 2009 21:18:58, Marc Khouzam wrote:
> 
> > > What exactly are you seeing?  I just run a few non-stop test
> > > (mi-nonstop.exp, mi-nsintrall.exp and ns-nsmoribund.exp tests)
> > > against linux x86-64 gdbserver head, and they passed cleanly for
> > > me, so *something* is working.  :-)
> > 
> > It seems no new thread is listed by GDB.
> 
> Hmmm, that should work.  This looks like another manifestation
> of PR threads/10048.  Does this make a difference?

Yes, this fixed the problem.
My Eclipse is still mis-behaving a bit, but that is probably
my code.  The 'info thread' does show all threads.

Heads up on a breakpoint mis-behavior coming in a separate mail :-)

Thanks!

>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Marc Khouzam | 1 May 2009 21:31
Picon
Favicon
Gravatar

Setting breakpoint misbehaving with all threads running in Non-Stop on Linux

Hi again,

I'm using HEAD (from yesterday) with Non-Stop locally on Linux.
I notice that when all my threads are running, setting a breakpoint
is misbehaving.

First, should I be able to set a breakpoint when all threads
are running (on Linux)?

Either way though, setting a bp reports an error -with-
a breakpoint id, and then 'info break' shows the breakpoint
as being set.  However, the breakpoint does not actually hit.

See below for the session.

Thanks

> gdb -i mi
~"GNU gdb (GDB) 6.8.50.20090430-cvs\n"
~"Copyright (C) 2009 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>\n"
~"This is free software: you are free to change and redistribute it.\n"
~"There is NO WARRANTY, to the extent permitted by law.  Type \"show
copying\"\n"
~"and \"show warranty\" for details.\n"
~"This GDB was configured as \"i686-pc-linux-gnu\".\n"
~"For bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
(gdb)
(Continue reading)

Permalink | Reply | 501 comments |
headers
Thiago Jung Bauermann | 2 May 2009 03:56
Picon

Re: Process record and replay checked in to main trunk

Hi Hui,

El jue, 30-04-2009 a las 16:02 +0800, Hui Zhu escribió:
> It was checked in today.
> Thanks for evey people that spent time on process record.  Precord
> can't be a part of gdb without your help.  Thank you very much.  :)

Congratulations! And thanks for your perseverance in getting this
functionality accepted! It was certainly no easy task, unfortunately.

My only regret is not having helped you more with this (in fact, I only
helped a little bit). For better or worse, all my GDB-related energy has
been directed to getting the Python branch merged in...

> And precord still has a long way to go.  There have a lot of thing need to do:

Thanks for this road map. IMHO this is the kind of thing that could go
on the wiki. In fact, I just added it under:

http://sourceware.org/gdb/wiki/ReversibleDebugging
--

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
Permalink | Reply | 1 comment |
headers
Eli Zaretskii | 2 May 2009 11:17
Picon

Re: Debugging a frameless function

> Date: Wed, 29 Apr 2009 15:12:16 -0400
> From: Daniel Jacobowitz <drow <at> false.org>
> Cc: gdb <at> sourceware.org
> 
> Mark's got a good point - some older GCC's just botch the debug info.
> What compiler are we looking at here?

For the record: this indeed turned out to be a compiler bug.
Upgrading to GCC 3.4.4 solved the problem.

Thanks to everybody for getting me on the right path.
Permalink | Reply | 0 comments |
headers
nagaraju.m | 2 May 2009 11:17
Favicon

Re: back trace issue

Hi Joel,
    I identified the function init_extraframe_info  [..]-tdep.c file. I 
made frame_info **prev* to point to previous frame and it is displaying 
all the frame.....
       but it is working only when we start the program from main (i.e 
when we break at main)...
       suppose if we break at some function XYZ called by main then it 
is not working...
     Is there any other file where we should provide this *prev* 
information......

Thanks,
Nagaraju

Joel Brobecker wrote:
>> can you please  suggest me where to provide the information  to gdb so  
>> that "back trace" works properly.....
>>     
>
> Typically, the [...]-tdep file for your architecture will provide
> a set of routines that compute the value of a register in the caller's
> frame (aka the "previous" frame) given a struct frame_info and and
> its associated frame cache. Have a look at some of the -tdep.c files,
> and search for "_prev_register", or "_this_id". That should give you
> a few leads. I'll also mention that there is a new module in
> prologue-value.[hc] that can simplify your job when doing prologue
> analysis. I am mentioning it because it's relatively use a still
> little used.
>
> Also, if your target supports DWARF, you might also want to see if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 2 May 2009 11:22
Picon

Re: Debugging a frameless function

> Date: Wed, 29 Apr 2009 21:08:44 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis <at> xs4all.nl>
> CC: drow <at> false.org, gdb <at> sourceware.org
> 
> > > Date: Wed, 29 Apr 2009 14:39:46 -0400
> > > From: Daniel Jacobowitz <drow <at> false.org>
> > > Cc: gdb <at> sourceware.org
> > 
> > Thanks for responding.
> > 
> > > Sounds like the debug info is bad.
> > 
> > But then why does GDB 6.1 have no problems debugging the same binary?
> 
> Did GDB 6.1 have the DWARF2 frame unwinder enabled for DJGPP?

Interestingly, it did, at least if my reading of the code is correct.

i386-tdep.c from GDB 6.1 says:

  /* Hook in the DWARF CFI frame unwinder.  */
  frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);

whereas in current CVS we have this instead:

  /* Hook in the DWARF CFI frame unwinder.  */
  dwarf2_append_unwinders (gdbarch);

and dwarf2_append_unwinders is simply
(Continue reading)

Permalink | Reply | 0 comments |
headers
kkcheng | 2 May 2009 17:29
Picon
Favicon

How does remote debugging work on image with symbol stripped?


I understand that with GDB, one can remote debug a program with symbol
stripped, as long as the host machine has an unstripped image.  My question
is how does it work and if it can be duplicate (easily) on other debugging
system as well.  I assume somehow stripping the debugging info does not
impact the code and data section, and wonder if images generated from
multiple elf files can go thru the same process.

Thanks,

KK
--

-- 
View this message in context: http://www.nabble.com/How-does-remote-debugging-work-on-image-with-symbol-stripped--tp23347162p23347162.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.
Permalink | Reply | 1 comment |
headers
Paul Pluzhnikov | 2 May 2009 17:57
Picon
Favicon

Re: How does remote debugging work on image with symbol stripped?

On Sat, May 2, 2009 at 8:29 AM, kkcheng <kkhcheng <at> hotmail.com> wrote:
>
> I understand that with GDB, one can remote debug a program with symbol
> stripped, as long as the host machine has an unstripped image.

Correct.

> My question is how does it work

GDB (on host) has access to all the debugging symbols, and communicates
with gdbserver (on target) to read/write memory/registers and to control
the inferior process.

> and if it can be duplicate (easily) on other debugging
> system as well.

Many other debuggers (e.g. TotalView and Microsoft Visual Studio)
implement a similar approach.

> I assume somehow stripping the debugging info does not
> impact the code and data section,

Correct: most object file formats keep debug info separate, precisely
so it can be stripped.

> and wonder if images generated from
> multiple elf files can go thru the same process.

Yes, ELF images linked from multiple ELF object files can be stripped.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pedro Alves | 2 May 2009 19:14

Re: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux

On Friday 01 May 2009 20:31:21, Marc Khouzam wrote:

> I'm using HEAD (from yesterday) with Non-Stop locally on Linux.
> I notice that when all my threads are running, setting a breakpoint
> is misbehaving.
> 
> First, should I be able to set a breakpoint when all threads
> are running (on Linux)?

I've worked with non-stop mode in a few targets other than linux
already, and so far, only linux has this issue, and it
is *really* a nuisance.  I've been thinking we should make it
possible on linux to insert breakpoints when threads are running
as well.  The user experience is just bad otherwise.

> Either way though, setting a bp reports an error -with-
> a breakpoint id, and then 'info break' shows the breakpoint
> as being set.  However, the breakpoint does not actually hit.
> 
> See below for the session.

> 
> (gdb) 
> info b
> &"info b\n"
> ~"Num     Type           Disp Enb Address    What\n"
> ~"1       breakpoint     keep y   0x080485dc in main at
> MultiThread.cc:24\n"
> ~"2       breakpoint     keep y   0x0804857a in thread_exec(void*) at
> MultiThread.cc:10\n"
(Continue reading)

Permalink | Reply | 502 comments |

Gmane