This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: no stack trace with 2.6.11 and gdb 6.3
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