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



   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


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