This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Merge of ARM Linux port with existing ARM code...


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.

Ok.

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

> 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
-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]