This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: problem with exec-file when targetting remote machine
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Kris Warkentin <kewarken at qnx dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 24 Mar 2003 15:36:53 -0500
- Subject: Re: problem with exec-file when targetting remote machine
- References: <003101c2f241$078b7050$0202040a@catdog>
On Mon, Mar 24, 2003 at 03:07:43PM -0500, Kris Warkentin wrote:
> This problem comes up when using the QNX remote protocol but it's probably
> more generic than that. I'm not asking for a fix but more for some guidance
> as to what might be happening.
>
> The long and short of it is that if I attach to a process on a remote
> machine after having read the symbols, everything works fine. I run gdb,
> load symbols, set a breakpoint on main, run and get:
>
> Breakpoint 1, main (argc=1, argv=0x803fcc4) at NetController.cpp:62
> 62 int lSuccessCode = 0; // Success
>
> as one might expect. If, however, exec-file has been set, either explicitly
> or implicitly by calling "gdb myapp" from the command line, I get something
> like:
>
> Breakpoint 1, 0x40380000 in ?? ()
> (gdb) bt
> #0 0x40380000 in ?? ()
> #1 0x00000001 in ?? ()
>
> Note that this doesn't happen with everything - it seems to be mostly with
> large projects, particularily C++. There's obviously some data being read
> by gdb based on what the exec-file is set as that is causing a problem.
>
> Can anyone give me an idea as to what gdb might be doing differently when
> exec-file has been set?
This means shared library handling is messed up, I bet. It only
triggers based on exec_bfd.
Probably the app is being relocated in memory by the shared library
code, and ending up wrong.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer