no stack trace with 2.6.11 and gdb 6.3

no stack trace with 2.6.11 and gdb 6.3

[Rich Coe]

I have been investigating a problem we found here, which initially
exactly matched the problem reported here:

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146087

    1. Start a 32-bit app on a x86_64 system
    2. attach with gdb
    3. backtrace starting in a system call doesn't work

Our versions:
    kernel: 2.6.11.11
    gdb: 6.3.0.0-1.21

After reviewing the patch made to bug#146087, I found that I can get
a valid traceback if I issue the following request:

    add-symbol-file-from-memory 0xffffe000

The interesting part is that this also failing on x86 systems, not just
x86_64.

If you start an application from within gdb on the command line, 
the following line is printed out:
    Loaded system supplied DSO at 0xffffe000

Which is apparently some internal gdb function executing the 
'add-symbol-file-from-memory' request that does not happen when attaching
to a running process.

I have a linux-2.6.7 system with gdb 6.0post-0.20040223.19rh that doesn't
have this problem.  

We have also replicated this problem on a current FC3 standard distribution
with gdb-6.3.0.0-1.21. The latest/last FC3 gdb shows the problem noted in the
bug report identified above.

How did we get this problem from gdb 6.0 to gdb 6.3 ?

-- 
Rich Coe		richard.coe@med.ge.com
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Fri, Jun 10, 2005 at 12:58:55PM -0500, Rich Coe wrote:
> I have been investigating a problem we found here, which initially
> exactly matched the problem reported here:
> 
>     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146087
> 
>     1. Start a 32-bit app on a x86_64 system
>     2. attach with gdb
>     3. backtrace starting in a system call doesn't work
> 
> Our versions:
>     kernel: 2.6.11.11
>     gdb: 6.3.0.0-1.21

This is presumably a bug in that Red Hat-supplied version of GDB.  We
can't help you with it on this list; if you can reproduce it with the
version of GDB in CVS, please let us know, otherwise you should discuss
it with Red Hat.

Code was added sometime last year to handle loading the vDSO on attach.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: no stack trace with 2.6.11 and gdb 6.3

[Rich Coe]

I downloaded the cvs snapshot gdb-6.3.50.20050607, built, and ran gdb 
and the problem still persists.

What next ?

On Fri, 10 Jun 2005 14:11:40 -0400
Daniel Jacobowitz <drow@false.org> wrote:
> On Fri, Jun 10, 2005 at 12:58:55PM -0500, Rich Coe wrote:
> > I have been investigating a problem we found here, which initially
> > exactly matched the problem reported here:
> > 
> >     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146087
> > 
> >     1. Start a 32-bit app on a x86_64 system
> >     2. attach with gdb
> >     3. backtrace starting in a system call doesn't work
> > 
> > Our versions:
> >     kernel: 2.6.11.11
> >     gdb: 6.3.0.0-1.21
> 
> This is presumably a bug in that Red Hat-supplied version of GDB.  We
> can't help you with it on this list; if you can reproduce it with the
> version of GDB in CVS, please let us know, otherwise you should discuss
> it with Red Hat.
> 
> Code was added sometime last year to handle loading the vDSO on attach.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
> 


-- 
Rich Coe		richard.coe@med.ge.com
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team

Re: no stack trace with 2.6.11 and gdb 6.3

[H. J. Lu]

On Fri, Jun 10, 2005 at 01:59:40PM -0500, Rich Coe wrote:
> I downloaded the cvs snapshot gdb-6.3.50.20050607, built, and ran gdb 
> and the problem still persists.
> 
> What next ?
> 

Try this.

BTW, why does's gdb use

http://www.sourceware.org/bugzilla/

It is very stupid not to.


H.J.
----
--- gdb/config/i386/linux64.mt.vdso	2004-11-11 16:47:07.000000000 -0800
+++ gdb/config/i386/linux64.mt	2005-02-01 13:01:46.056022932 -0800
@@ -1,5 +1,5 @@
 # Target: GNU/Linux x86-64
 TDEPFILES= amd64-tdep.o amd64-linux-tdep.o \
 	i386-tdep.o i387-tdep.o i386-linux-tdep.o glibc-tdep.o \
-	solib.o solib-svr4.o corelow.o
+	solib.o solib-svr4.o corelow.o symfile-mem.o
 DEPRECATED_TM_FILE= solib.h

Re: no stack trace with 2.6.11 and gdb 6.3

[Christopher Faylor]

On Fri, Jun 10, 2005 at 12:05:32PM -0700, H. J. Lu wrote:
>BTW, why does's gdb use
>
>http://www.sourceware.org/bugzilla/
>
>It is very stupid not to.

AFAIK, gdb is still using gnats.

cgf

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Fri, Jun 10, 2005 at 12:05:32PM -0700, H. J. Lu wrote:
> On Fri, Jun 10, 2005 at 01:59:40PM -0500, Rich Coe wrote:
> > I downloaded the cvs snapshot gdb-6.3.50.20050607, built, and ran gdb 
> > and the problem still persists.
> > 
> > What next ?
> > 
> 
> Try this.
> 
> BTW, why does's gdb use
> 
> http://www.sourceware.org/bugzilla/
> 
> It is very stupid not to.

Because we have PR numbers all through the source and testsuite, and
don't want to ditch them.  We will need a third bugzilla setup,
probably.  I need to find some time to talk to Dan about it.

> @@ -1,5 +1,5 @@
>  # Target: GNU/Linux x86-64
>  TDEPFILES= amd64-tdep.o amd64-linux-tdep.o \
>  	i386-tdep.o i387-tdep.o i386-linux-tdep.o glibc-tdep.o \
> -	solib.o solib-svr4.o corelow.o
> +	solib.o solib-svr4.o corelow.o symfile-mem.o
>  DEPRECATED_TM_FILE= solib.h

Since he had the add-symbol-file-from-memory command already, that
can't be it, can it?  But you're right, it's a bug that it's missing
from linux64.mt.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: no stack trace with 2.6.11 and gdb 6.3

[Rich Coe]

Yes, after I manually run
    'add-symbol-file-from-memory 0xffffe000'
I can get a valid traceback.  

Why doesn't this just work like gdb-6.0 on 2.6.7 ?
Why does this command run automatically when debugging with gdb from the
command line but when attaching to an already running process ?

R.

On Fri, 10 Jun 2005 12:05:32 -0700
"H. J. Lu" <hjl@lucon.org> wrote:
> On Fri, Jun 10, 2005 at 01:59:40PM -0500, Rich Coe wrote:
> > I downloaded the cvs snapshot gdb-6.3.50.20050607, built, and ran gdb 
> > and the problem still persists.
> > 
> > What next ?
> > 
> 
> Try this.
> 
> BTW, why does's gdb use
> 
> http://www.sourceware.org/bugzilla/
> 
> It is very stupid not to.
> 
> 
> H.J.
> ----
> --- gdb/config/i386/linux64.mt.vdso	2004-11-11 16:47:07.000000000 -0800
> +++ gdb/config/i386/linux64.mt	2005-02-01 13:01:46.056022932 -0800
> @@ -1,5 +1,5 @@
>  # Target: GNU/Linux x86-64
>  TDEPFILES= amd64-tdep.o amd64-linux-tdep.o \
>  	i386-tdep.o i387-tdep.o i386-linux-tdep.o glibc-tdep.o \
> -	solib.o solib-svr4.o corelow.o
> +	solib.o solib-svr4.o corelow.o symfile-mem.o
>  DEPRECATED_TM_FILE= solib.h
> 


-- 
Rich Coe		richard.coe@med.ge.com
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Fri, Jun 10, 2005 at 02:20:58PM -0500, Rich Coe wrote:
> Yes, after I manually run
>     'add-symbol-file-from-memory 0xffffe000'
> I can get a valid traceback.  
> 
> Why doesn't this just work like gdb-6.0 on 2.6.7 ?

Your GDB 6.0 was also patched by Red Hat; again, you would have to ask
them.

> Why does this command run automatically when debugging with gdb from the
> command line but when attaching to an already running process ?

Because it's different code that detects the new program.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: no stack trace with 2.6.11 and gdb 6.3

[richard.coe]

Daniel Jacobowitz writes:
In a message dated: Fri, 10 Jun 2005 15:37:21 EDT
> On Fri, Jun 10, 2005 at 02:20:58PM -0500, Rich Coe wrote:
> > Yes, after I manually run
> >     'add-symbol-file-from-memory 0xffffe000'
> > I can get a valid traceback.  
> > 
> > Why doesn't this just work like gdb-6.0 on 2.6.7 ?
> 
> Your GDB 6.0 was also patched by Red Hat; again, you would have to ask
> them.

    In this regard, you are shallow.  I think every developer has a 
    certain expectation that when they type backtrace, that the debugger
    accurately display the data.  I was merely referencing a previously 
    release where it works, and now it doesn't.  

    There is an obvious difference that this is not working. 
    I'm all for working towards a solution and I don't think you taking pot
    shots at Redhat is working toward that end.  If you have a beef with
    Redhat, I could care less.  If you are saying or implying that this is
    broken only in a Redhat kernel, then please be less obtuse, because
    I'll gladly track this problem down wherever it may lead.
> 
> > Why does this command run automatically when debugging with gdb from the
> > command line but when attaching to an already running process ?
> 
> Because it's different code that detects the new program.

    So it seems that you are well aware of this problem. 
    Are you recommending that the add-symbol-file-from-memory as the
    current solution ?

    I've downloaded the current cvs and faced the same problem.
    So it seems that a half-solution to this problem which was discovered
    and fixed in February, is not even in the current CVS.

    If need me to enter it into bugzilla, I'm happy to do that.  
    Just let me know where.

    I researched this problem before posting my findings here. 
    I'm just looking for developing the correct solution.

    Thanks.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
--
Rich Coe		richard.coe@med.ge.com
General Electric Medical Systems

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Fri, Jun 10, 2005 at 04:15:59PM -0500, richard.coe@med.ge.com wrote:
> 
> Daniel Jacobowitz writes:
> In a message dated: Fri, 10 Jun 2005 15:37:21 EDT
> > On Fri, Jun 10, 2005 at 02:20:58PM -0500, Rich Coe wrote:
> > > Yes, after I manually run
> > >     'add-symbol-file-from-memory 0xffffe000'
> > > I can get a valid traceback.  
> > > 
> > > Why doesn't this just work like gdb-6.0 on 2.6.7 ?
> > 
> > Your GDB 6.0 was also patched by Red Hat; again, you would have to ask
> > them.
> 
>     In this regard, you are shallow.  I think every developer has a 
>     certain expectation that when they type backtrace, that the debugger
>     accurately display the data.  I was merely referencing a previously 
>     release where it works, and now it doesn't.  
> 
>     There is an obvious difference that this is not working. 
>     I'm all for working towards a solution and I don't think you taking pot
>     shots at Redhat is working toward that end.  If you have a beef with
>     Redhat, I could care less.  If you are saying or implying that this is
>     broken only in a Redhat kernel, then please be less obtuse, because
>     I'll gladly track this problem down wherever it may lead.

Kindly don't be insulting.  I'm not "taking a potshot at Red Hat".  I
know for an absolute fact that GDB 6.0 would not load a vsyscall DSO
and automatically backtrace from it.  If you have a GDB 6.0-<something>
which does, then the patches came from elsewhere, and I can't answer
questions about code we don't have.

> > > Why does this command run automatically when debugging with gdb from the
> > > command line but when attaching to an already running process ?
> > 
> > Because it's different code that detects the new program.
> 
>     So it seems that you are well aware of this problem. 
>     Are you recommending that the add-symbol-file-from-memory as the
>     current solution ?

No, I told you that I expected it to work in CVS.  If it does not, then
someone needs to reproduce your problem using an unpatched GDB and
debug it.  I do not have a Red Hat x86_64 system on which to reproduce
it, but I may be able to elsewhere - if I have time.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: no stack trace with 2.6.11 and gdb 6.3

[H. J. Lu]

On Fri, Jun 10, 2005 at 08:51:13PM -0400, Daniel Jacobowitz wrote:
> 
> No, I told you that I expected it to work in CVS.  If it does not, then
> someone needs to reproduce your problem using an unpatched GDB and
> debug it.  I do not have a Red Hat x86_64 system on which to reproduce
> it, but I may be able to elsewhere - if I have time.

Gdb should support vDSO on Linux 2.6.11/x86_64 with this patch:

http://sources.redhat.com/ml/gdb/2005-06/msg00095.html

If it doesn't work, I will be interested to know.



H.J.

Re: no stack trace with 2.6.11 and gdb 6.3

[Rich Coe]

On Fri, 10 Jun 2005 19:21:48 -0700
"H. J. Lu" <hjl@lucon.org> wrote:
> On Fri, Jun 10, 2005 at 08:51:13PM -0400, Daniel Jacobowitz wrote:
> > 
> > No, I told you that I expected it to work in CVS.  If it does not, then
> > someone needs to reproduce your problem using an unpatched GDB and
> > debug it.  I do not have a Red Hat x86_64 system on which to reproduce
> > it, but I may be able to elsewhere - if I have time.
> 
> Gdb should support vDSO on Linux 2.6.11/x86_64 with this patch:
> 
> http://sources.redhat.com/ml/gdb/2005-06/msg00095.html
> 
> If it doesn't work, I will be interested to know.
> H.J.

The patch makes it work only if you start the program from the gdb
command line.  As I said in my original post:
> After reviewing the patch made to bug#146087, I found that I can get
> a valid traceback if I issue the following request:
>
>    add-symbol-file-from-memory 0xffffe000
> The interesting part is that this also failing on x86 systems, not just
> x86_64.
> 
> If you start an application from within gdb on the command line, 
> the following line is printed out:
>     Loaded system supplied DSO at 0xffffe000

-- 
Rich Coe		richard.coe@med.ge.com
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team

Re: no stack trace with 2.6.11 and gdb 6.3

[H. J. Lu]

On Mon, Jun 13, 2005 at 10:16:29AM -0500, Rich Coe wrote:
> On Fri, 10 Jun 2005 19:21:48 -0700
> "H. J. Lu" <hjl@lucon.org> wrote:
> > On Fri, Jun 10, 2005 at 08:51:13PM -0400, Daniel Jacobowitz wrote:
> > > 
> > > No, I told you that I expected it to work in CVS.  If it does not, then
> > > someone needs to reproduce your problem using an unpatched GDB and
> > > debug it.  I do not have a Red Hat x86_64 system on which to reproduce
> > > it, but I may be able to elsewhere - if I have time.
> > 
> > Gdb should support vDSO on Linux 2.6.11/x86_64 with this patch:
> > 
> > http://sources.redhat.com/ml/gdb/2005-06/msg00095.html
> > 
> > If it doesn't work, I will be interested to know.
> > H.J.
> 
> The patch makes it work only if you start the program from the gdb
> command line.  As I said in my original post:

You are saying:

1.

# gdb foo

works.

2. But 

# foo
# gdb foo pid

doesn't work?

Tell me how to reproduce it. I will take a look.


H.J.

Re: no stack trace with 2.6.11 and gdb 6.3

[Rich Coe]

On Mon, 13 Jun 2005 08:26:46 -0700
"H. J. Lu" <hjl@lucon.org> wrote:
> On Mon, Jun 13, 2005 at 10:16:29AM -0500, Rich Coe wrote:
> > On Fri, 10 Jun 2005 19:21:48 -0700
> > "H. J. Lu" <hjl@lucon.org> wrote:
> > > On Fri, Jun 10, 2005 at 08:51:13PM -0400, Daniel Jacobowitz wrote:
> > > > 
> > > > No, I told you that I expected it to work in CVS.  If it does not, then
> > > > someone needs to reproduce your problem using an unpatched GDB and
> > > > debug it.  I do not have a Red Hat x86_64 system on which to reproduce
> > > > it, but I may be able to elsewhere - if I have time.
> > > 
> > > Gdb should support vDSO on Linux 2.6.11/x86_64 with this patch:
> > > 
> > > http://sources.redhat.com/ml/gdb/2005-06/msg00095.html
> > > 
> > > If it doesn't work, I will be interested to know.
> > > H.J.
> > 
> > The patch makes it work only if you start the program from the gdb
> > command line.  As I said in my original post:
> 
> You are saying:
> 
> 1.  # gdb foo
>     works.
> 
> 2. But 
> # foo 
    # foo &
> # gdb foo pid
> doesn't work?

    Yes.

> Tell me how to reproduce it. I will take a look.
> 

    Compile the following program, -m32.
    run it in the background, and attach with gdb.
    get a bt.

Results:
gdb gtest 29769
GNU gdb Red Hat Linux (6.3.0.0-1.10rh)
Copyright 2004 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 "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Attaching to program: /data/rhcoe/data/mr/gtest, process 29769
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe405 in ?? ()
(gdb) bt
#0  0xffffe405 in ?? ()
#1  0xffffd9f8 in ?? ()
#2  0x4ba3e45d in ___newselect_nocancel () from /lib/tls/libc.so.6
#3  0x080484fe in myselect ()
#4  0x00000000 in ?? ()
(gdb) add-symbol-file-from-memory 0xffffe000
Reading symbols from shared object read from target memory...done.
(gdb) bt
#0  0xffffe405 in __kernel_vsyscall ()
#1  0x4ba3e45d in ___newselect_nocancel () from /lib/tls/libc.so.6
#2  0x080484fe in myselect ()
#3  0x08048565 in func_two ()
#4  0x0804858e in func_one ()
#5  0x080485cf in main ()

-- 
Rich Coe		richard.coe@med.ge.com
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team

Re: no stack trace with 2.6.11 and gdb 6.3

[H. J. Lu]

On Mon, Jun 13, 2005 at 10:34:12AM -0500, Rich Coe wrote:
> On Mon, 13 Jun 2005 08:26:46 -0700
> "H. J. Lu" <hjl@lucon.org> wrote:
> > On Mon, Jun 13, 2005 at 10:16:29AM -0500, Rich Coe wrote:
> > > On Fri, 10 Jun 2005 19:21:48 -0700
> > > "H. J. Lu" <hjl@lucon.org> wrote:
> > > > On Fri, Jun 10, 2005 at 08:51:13PM -0400, Daniel Jacobowitz wrote:
> > > > > 
> > > > > No, I told you that I expected it to work in CVS.  If it does not, then
> > > > > someone needs to reproduce your problem using an unpatched GDB and
> > > > > debug it.  I do not have a Red Hat x86_64 system on which to reproduce
> > > > > it, but I may be able to elsewhere - if I have time.
> > > > 
> > > > Gdb should support vDSO on Linux 2.6.11/x86_64 with this patch:
> > > > 
> > > > http://sources.redhat.com/ml/gdb/2005-06/msg00095.html
> > > > 
> > > > If it doesn't work, I will be interested to know.
> > > > H.J.
> > > 
> > > The patch makes it work only if you start the program from the gdb
> > > command line.  As I said in my original post:
> > 
> > You are saying:
> > 
> > 1.  # gdb foo
> >     works.
> > 
> > 2. But 
> > # foo 
>     # foo &
> > # gdb foo pid
> > doesn't work?
> 
>     Yes.
> 
> > Tell me how to reproduce it. I will take a look.
> > 
> 
>     Compile the following program, -m32.
>     run it in the background, and attach with gdb.
>     get a bt.
> 
> Results:
> gdb gtest 29769
> GNU gdb Red Hat Linux (6.3.0.0-1.10rh)
> Copyright 2004 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 "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
> 
> Attaching to program: /data/rhcoe/data/mr/gtest, process 29769
> Reading symbols from /lib/tls/libc.so.6...done.
> Loaded symbols for /lib/tls/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> 0xffffe405 in ?? ()
> (gdb) bt
> #0  0xffffe405 in ?? ()
> #1  0xffffd9f8 in ?? ()
> #2  0x4ba3e45d in ___newselect_nocancel () from /lib/tls/libc.so.6
> #3  0x080484fe in myselect ()
> #4  0x00000000 in ?? ()
> (gdb) add-symbol-file-from-memory 0xffffe000
> Reading symbols from shared object read from target memory...done.
> (gdb) bt
> #0  0xffffe405 in __kernel_vsyscall ()
> #1  0x4ba3e45d in ___newselect_nocancel () from /lib/tls/libc.so.6
> #2  0x080484fe in myselect ()
> #3  0x08048565 in func_two ()
> #4  0x0804858e in func_one ()
> #5  0x080485cf in main ()

You also need this patch for gdb 6.3.


H.J.
--- gdb/inftarg.c.attach	2004-11-11 16:46:57.000000000 -0800
+++ gdb/inftarg.c	2005-06-13 13:07:14.000000000 -0700
@@ -211,6 +211,10 @@ child_attach (char *args, int from_tty)
   
   inferior_ptid = pid_to_ptid (pid);
   push_target (&deprecated_child_ops);
+
+  /* Do this first, before anything has had a chance to query the
+     inferiors symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 #if !defined(CHILD_POST_ATTACH)

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Mon, Jun 13, 2005 at 01:13:50PM -0700, H. J. Lu wrote:
> You also need this patch for gdb 6.3.
> 
> 
> H.J.
> --- gdb/inftarg.c.attach	2004-11-11 16:46:57.000000000 -0800
> +++ gdb/inftarg.c	2005-06-13 13:07:14.000000000 -0700
> @@ -211,6 +211,10 @@ child_attach (char *args, int from_tty)
>    
>    inferior_ptid = pid_to_ptid (pid);
>    push_target (&deprecated_child_ops);
> +
> +  /* Do this first, before anything has had a chance to query the
> +     inferiors symbol table or similar.  */
> +  observer_notify_inferior_created (&current_target, from_tty);
>  }
>  
>  #if !defined(CHILD_POST_ATTACH)
> 

Which is already in GDB CVS, which Rich has already said did not work
for him.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: no stack trace with 2.6.11 and gdb 6.3

[H. J. Lu]

On Mon, Jun 13, 2005 at 04:16:35PM -0400, Daniel Jacobowitz wrote:
> On Mon, Jun 13, 2005 at 01:13:50PM -0700, H. J. Lu wrote:
> > You also need this patch for gdb 6.3.
> > 
> > 
> > H.J.
> > --- gdb/inftarg.c.attach	2004-11-11 16:46:57.000000000 -0800
> > +++ gdb/inftarg.c	2005-06-13 13:07:14.000000000 -0700
> > @@ -211,6 +211,10 @@ child_attach (char *args, int from_tty)
> >    
> >    inferior_ptid = pid_to_ptid (pid);
> >    push_target (&deprecated_child_ops);
> > +
> > +  /* Do this first, before anything has had a chance to query the
> > +     inferiors symbol table or similar.  */
> > +  observer_notify_inferior_created (&current_target, from_tty);
> >  }
> >  
> >  #if !defined(CHILD_POST_ATTACH)
> > 
> 
> Which is already in GDB CVS, which Rich has already said did not work
> for him.
> 

He was using gdb 6.3, not gdb head. See

http://sources.redhat.com/ml/gdb/2005-06/msg00114.html


H.J.

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Mon, Jun 13, 2005 at 01:30:46PM -0700, H. J. Lu wrote:
> He was using gdb 6.3, not gdb head. See
> 
> http://sources.redhat.com/ml/gdb/2005-06/msg00114.html

http://sources.redhat.com/ml/gdb/2005-06/msg00094.html

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: no stack trace with 2.6.11 and gdb 6.3

[Rich Coe]

On Mon, 13 Jun 2005 08:26:46 -0700
"H. J. Lu" <hjl@lucon.org> wrote:
> On Mon, Jun 13, 2005 at 10:16:29AM -0500, Rich Coe wrote:
> > On Fri, 10 Jun 2005 19:21:48 -0700
> > "H. J. Lu" <hjl@lucon.org> wrote:
> > > On Fri, Jun 10, 2005 at 08:51:13PM -0400, Daniel Jacobowitz wrote:
> > > > 
> > > > No, I told you that I expected it to work in CVS.  If it does not, then
> > > > someone needs to reproduce your problem using an unpatched GDB and
> > > > debug it.  I do not have a Red Hat x86_64 system on which to reproduce
> > > > it, but I may be able to elsewhere - if I have time.
> > > 
> > > Gdb should support vDSO on Linux 2.6.11/x86_64 with this patch:
> > > 
> > > http://sources.redhat.com/ml/gdb/2005-06/msg00095.html
> > > 
> > > If it doesn't work, I will be interested to know.
> > > H.J.
> > 
> > The patch makes it work only if you start the program from the gdb
> > command line.  As I said in my original post:
> 

I found out what I was not seeing on Friday. 
The original use case used 'gdb -p PID', and it still did not work.
I've found this message from gdb though:
    warning: Could not load vsyscall page because no executable was specified

If I invoke it gdb with 'gdb gtest PID', then the current gdb cvs version
works as expected. 

Is /proc/PID/exe linux specific ?

I need to look at the -p invocation.

BTW, the cvs version is missing this patch:
--- gdb/config/i386/linux64.mt.vdso	2004-11-11 16:47:07.000000000 -0800
+++ gdb/config/i386/linux64.mt	2005-02-01 13:01:46.056022932 -0800
@@ -1,5 +1,5 @@
 # Target: GNU/Linux x86-64
 TDEPFILES= amd64-tdep.o amd64-linux-tdep.o \
 	i386-tdep.o i387-tdep.o i386-linux-tdep.o glibc-tdep.o \
-	solib.o solib-svr4.o corelow.o
+	solib.o solib-svr4.o corelow.o symfile-mem.o
 DEPRECATED_TM_FILE= solib.h

R.
-- 
Rich Coe		richard.coe@med.ge.com
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team

Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz]

On Mon, Jun 13, 2005 at 03:34:27PM -0500, Rich Coe wrote:
> I found out what I was not seeing on Friday. 
> The original use case used 'gdb -p PID', and it still did not work.
> I've found this message from gdb though:
>     warning: Could not load vsyscall page because no executable was specified
> 
> If I invoke it gdb with 'gdb gtest PID', then the current gdb cvs version
> works as expected. 
> 
> Is /proc/PID/exe linux specific ?
> 
> I need to look at the -p invocation.
> 
> BTW, the cvs version is missing this patch:
> --- gdb/config/i386/linux64.mt.vdso	2004-11-11 16:47:07.000000000 -0800
> +++ gdb/config/i386/linux64.mt	2005-02-01 13:01:46.056022932 -0800
> @@ -1,5 +1,5 @@
>  # Target: GNU/Linux x86-64
>  TDEPFILES= amd64-tdep.o amd64-linux-tdep.o \
>  	i386-tdep.o i387-tdep.o i386-linux-tdep.o glibc-tdep.o \
> -	solib.o solib-svr4.o corelow.o
> +	solib.o solib-svr4.o corelow.o symfile-mem.o
>  DEPRECATED_TM_FILE= solib.h
> 

OK, now we're talking.  That warning says, on the following line,
"please use the file command first"; so I'm glad to hear that 'gdb
gtest PID' works OK.

The problem arises because we load /proc/PID/exe after we check for the
vsyscall DSO.  They're in very different places, so it'll take a little
prodding to get them to happen in the right order.  One way would be to
move the inferior-created observer later, but I'm not sure if the other
users of this observer should happen early or late.

-- 
Daniel Jacobowitz
CodeSourcery, LLC