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

[Scott Bambrough <scottb@netwinder.org>]

Philip Blundell wrote:
> 
> 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?

We have actually discussed the problem before Phil.  It is the problem
with predicated instructions and breakpoints.  The messages actually did
go to the list.  I have included the archive urls below.

These are the messages in question:

http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00163.html
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00365.html

Cheers,

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From shebs@cygnus.com Wed Dec 15 11:54:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: Philip.Blundell@pobox.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Merge of ARM Linux port with existing ARM code...
Date: Wed, 15 Dec 1999 11:54:00 -0000
Message-id: <199912151954.LAA07033@andros.cygnus.com>
References: <E11yJCG-0005dx-00@kings-cross.london.uk.eu.org>
X-SW-Source: 1999-q4/msg00393.html
Content-length: 1024

   Date: Wed, 15 Dec 1999 18:30:43 +0000
   From: Philip Blundell <Philip.Blundell@pobox.com>

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

The original was posted to gdb-patches by Scott B on 3 November; URL is
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00163.html .

								Stan
From shebs@cygnus.com Wed Dec 15 14:06:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: scottb@netwinder.org
Cc: jingham@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Merge of ARM Linux port with existing ARM code...
Date: Wed, 15 Dec 1999 14:06:00 -0000
Message-id: <199912152124.NAA07105@andros.cygnus.com>
References: <3857DC13.438069C4@netwinder.org>
X-SW-Source: 1999-q4/msg00394.html
Content-length: 3309

   Date: Wed, 15 Dec 1999 13:21:07 -0500
   From: Scott Bambrough <scottb@netwinder.org>

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

Yes.  It took longer than I expected to separate the cosmetic changes
from the functional changes; in general we don't like to put in mixes
of both, because it becomes very difficult to track down the causes of
problems later on.  ARM is getting a lot of attention right now, so I
need to be careful not to crumble anything...

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

By "embedded ARM" I meant the arm-{elf,coff} configs, which are mainly
for bare boards with little or no OS.  Embedded ARM Linux is an
interesting issue though; should the GDB for it be the generic arm-elf
GDB or a new and different config?  At this point I don't know; for
EL/IX experimentation I think they're using a standard cross GDB, but
that will need to change to accommodate all four levels of the EL/IX
API. ( http://sourceware.cygnus.com/elix for EL/IX info)

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

You're right about the size of the descrepancy between -O0 and -O2,
but I think it's going a bit far to say "there is no point in
debugging unoptimized code".  Almost all of my own debugging work is
done on unoptimized code.

GDB's official position on optimized code is to allow the debugger to
work with it, but not to promise very much functionality.  -O2 in GCC
includes ever-more-aggressive optimizations, and it's going to be hard
or impossible for GDB to reconstruct the original code in all cases.
Conditional moves are a primo example - you have a single instruction
that is an amalgam of several source lines, and you want GDB to
present the illusion that it can do several statement-level steps,
when the actual hardware will do only one instruction-level step.  For
GDB, an instruction-level step is an atomic operation.  How do you
divide up an atom?  (Use a cyclotron, of course :-) )

The problems here are very deep and common to all debugging.  If you
review the research literature, it's clear that while there's been
some progress, it's still too limited in scope to be really useful for
GDB.  Still, it would be cool for someone to extend the state of the
art and demo it in GDB first - any volunteers?

								Stan