This is the mail archive of the
mailing list for the GDB project.
Re: Merge of ARM Linux port with existing ARM code...
- To: Stan Shebs <shebs at cygnus dot com>
- Subject: Re: Merge of ARM Linux port with existing ARM code...
- From: Scott Bambrough <scottb at netwinder dot org>
- Date: Wed, 15 Dec 1999 13:21:07 -0500
- CC: jingham at cygnus dot com, gdb-patches at sourceware dot cygnus dot com
- Organization: Rebel.com
- References: <199912110049.QAA11719@andros.cygnus.com>
Stan Shebs wrote:
> Actually, the embed config doesn't need .mh, nm, or xm files, so I'm
> leaving those out. The rest of these files look fine, and I'm basically
> putting them in verbatim.
That's great. Thanks.
> I'm going to be marking arm-xdep.c as obsolete, as I've done with
> other files. They'll be around for the next releases, then disappear
> sometime after that.
> That's a great start in the right direction. We can always come back
> and polish the code later on. I'll get the basic stuff in, then you
> can check it over in the next snap and tell me what I missed.
It doesn't seem to be in this weeks snapshot, will it be in next weeks?
> Shared library support:
> Both targets make use of IN_SOLIB_CALL_TRAMPOLINE. This needs to be
> resolved for ARM-Thumb compatibility. At the moment this is not
> implemented on Linux, and Thumb is not an issue on Linux (at this very
> moment at least). I have to get this support going, and I will resolve
> it then.
> Embedded ARM won't care about this one.
Are you sure? If the embedded Linux project takes off, this may become
> I suspect this issue has always been around, but nobody has noticed
> because you don't get the move+condition in unoptimized code. Optimized
> code debugging will be squirrelly like it always is.
There is no point in debugging unoptimized code. The generated code for
-O0/-O2 is so different, it rarely suffers from the same problems. This
has been my experience.
> The usual approach to solving this kind of problem is to copy the
> instructions somewhere else and execute them there. It's really hairy
> to make work, usually implementors try to avoid the situation. But in
> the ARM case, you would break the instruction into a multi-instruction
> sequence consisting of simpler instructions, then put the breakpoint
> at the simpler instruction that best corresponds to the source location.
> There would be some guessing as to which instruction was meant...
This sounds like a horrible hack. I'll think about it.
Scott Bambrough - Software Engineer