Re: no stack trace with 2.6.11 and gdb 6.3

[Daniel Jacobowitz <drow@false.org>]

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