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

[Scott Bambrough <scottb@netwinder.org>]

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
From Philip.Blundell@pobox.com Wed Dec 15 10:31:00 1999
From: Philip Blundell <Philip.Blundell@pobox.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Stan Shebs <shebs@cygnus.com>, jingham@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Merge of ARM Linux port with existing ARM code... 
Date: Wed, 15 Dec 1999 10:31:00 -0000
Message-id: <E11yJCG-0005dx-00@kings-cross.london.uk.eu.org>
References: <199912110049.QAA11719@andros.cygnus.com> <3857DC13.438069C4@netwinder.org>
X-SW-Source: 1999-q4/msg00389.html
Content-length: 752

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

For the benefit of those of us who didn't see your original message (I guess 
it wasn't posted to the list), could you explain what the problem in question 
actually is?

Thanks

p.