This is the mail archive of the 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, 03 Nov 1999 14:57:47 -0500
   From: Scott Bambrough <>

   I've made two targets in the configure scripts for ARM: linux and
   embedded.  Basically I have:

   in gdb/config/arm:,, nm-embed.h, tm-embed.h, xm-embed.h,, nm-linux.h, tm-linux.h, xm-linux.h

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.

   Most files are very short.  The bulk of the definitions are in tm-arm.h.
   tm-linux.h and tm-embed.h both include this and add/override anything

   in gdb:

   arm-tdep.c, armlinux-nat.c, arm-xdep.o

   Again, the bulk of the code is in arm-tdep.c.  armlinux-nat.c contains
   stuff specific to linux.  I'm not sure what to make of the code in
   arm-xdep.c.  The Linux target makes no use of it, but the embedded
   target does.  Much of it seems geared towards an Acorn machines.
   I have left it alone.  You should have a look at it.

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.

   If something doesn't seem right, or you don't like what I have done,
   please say so.  Nothing is written in stone.  I took the liberty of
   converting all the code to ANSI (except arm-xdep.c) and started
   converting all the macros in tm-arm.h to functions in preparation for
   being multi-arch friendly.  I'm certain I have missed a few though.  I
   intend to revisit the code.

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.

   I don't have suitable environments to test:


I'll be testing this, for crosses.

   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.

   Note: There is code in arm-tdep.c for the new call dummy scheme.  It was
   written by Cygnus, and I think Cygnus should enable it and verify its


   I believe I have resolved Andrew Cagney's objections regarding the
   breakpoint code.  The global BREAKPOINT macros are gone, and have been
   replaced by arm_breakpoint_from_pc(), and macros used to define the
   various types of breakpoints.  I have added commments as he suggested
   indicating why things are as they are.  The following problem with
   breakpoints still needs to be resolved however:

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.

   This could be solved by having breakpoint_from_pc() read the instruction
   at the PC, and merge the condition bits into the breakpoint.  Then the
   breakpoint will only be executed under the same conditions as the
   original instruction.

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


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