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, 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