problem with exec-file when targetting remote machine

problem with exec-file when targetting remote machine

[Kris Warkentin]

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?

cheers,

Kris

Re: problem with exec-file when targetting remote machine

[Daniel Jacobowitz]

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

Re: problem with exec-file when targetting remote machine

[Kris Warkentin]

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

I think I maybe misled you in the beginning with this.  I had been told that
it affected all targets but it seems that it affects sh4 but not x86.  I
don't know about our other platforms.

By brute force and stupidity I determined that in exec.c:exec_file_attach()
there is a call to set_gdbarch_from_file().  This is what causes the screw
up.  It looks like something is getting buggered up in there, possibly
because the architecture is not getting recognized properly from the file
and the defaults aren't working.

Can anyone tell me the possible ramifications of commenting out this line?
I wouldn't normally contemplate this kind of fix but I have only a short
while to get this in a patch.  In my preliminary tests, everything seems to
work but I'm worried that there might be other consequences.

cheers,

Kris

Re: problem with exec-file when targetting remote machine

[Andrew Cagney]

> Can anyone tell me the possible ramifications of commenting out this line?
> I wouldn't normally contemplate this kind of fix but I have only a short
> while to get this in a patch.  In my preliminary tests, everything seems to
> work but I'm worried that there might be other consequences.

Assume the code was originally added because of a bug :-)  I'm guessing 
something like:

(gdb) file executable
(gdb) disassemble main

will break.  It will select the wrong disassembler.  Why isn't the 
executable being recognized, and why do the defaults fail?  (NickC 
pointed me at an endian problem recently).

Andrew

Re: problem with exec-file when targetting remote machine

[Kris Warkentin]

> Assume the code was originally added because of a bug :-)  I'm guessing
> something like:
>
> (gdb) file executable
> (gdb) disassemble main
>
> will break.  It will select the wrong disassembler.  Why isn't the
> executable being recognized, and why do the defaults fail?  (NickC
> pointed me at an endian problem recently).

In case anyone is curious as to what the problem was, here it is.

I was suspicious about the $pc being incorrect even though it hit the
breakpoint at main.  I stepped into our register stuffing code and observed
that everything was fine.  As soon as I continued and checked the registers,
they were changed but only from $r15 onward (this is an sh4 target).  I set
a watchpoint and it turns out that our floating point stuffing routine was
calculating the offset incorrectly and clobbering some of the gp registers.

The reason it was only happening with exec-file is that the default sh arch
wasn't retrieving fpregs and when it got a slightly different arch based on
the bfd, it would start asking for them and they'd get clobbered.

Cheers,

Kris