This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


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

Re: support for ARM GNU/Linux


Philip Blundell wrote:
> 
> In message <np90bx1a3v.fsf@zwingli.cygnus.com>, Jim Blandy writes:
> >Could you adapt your patches to 4.18?  If I try to do it and anything
> >non-trivial comes up, I'd almost certainly screw them up.
> >
> >Could you rename the native file armlinux-nat.c?  "lnx" looks like
> >"lynx", which is something else entirely...  :)
> 
> Sure.  I've appended here a new patch incorporating those changes.  It's
> against the 19990412 snapshot.

Hello,


I'm afraid that you've drawn the short straw - the way targets are
implemented is changing.  In fact, one change I refer to below won't be
visible until the *next* snapshot.

The unfortunate consequence is that there is going to need to be more
work before this change can be integrated into GDB proper.  On the
bright side, if you bare with me, we will have greatly simplified the
task of evolving the ARM GDB into a debugger that can support several
different architectures.


--


The file gdb/armlinux-tdep.c will need tidying.  Check the Gnu
Programming Standars document -
http://www.fsf.org/prep/standards_toc.html .  It would be good to get
any new files correctly formatted from day one (even if all the old ones
are still a mess :-).


--


You've used the *_BREAKPOINT macro's.  In the process, the change:

	Tue Nov 24 14:13:10 1998  Andrew Cagney  <cagney@chook>

	* config/arm/tm-arm.h ({BIG,LITTLE}_BREAKPOINT): Delete macros.
 	({ARM,THUMB}_{BE,LE}_BREAKPOINT): Move macros from here.
	* arm-tdep.c: To here.

was reversed.  The use of the *_BREAKPOINT macros is going to be
discouraged.  Instead you are encouraged to use a function, called via
the macro BREAKPOINT_FROM_PC() (ref gdbint.texinfo).  In the case of the
ARM, BREAKPOINT_FROM_PC() maps onto the function
arm_breakpoint_from_pc().  That function should be coded so that it can
determine the required breakpoint without having to revert to compile
time CPP directives such as #undef, #define or #if.

If you feal that a new implementation of the breakpoint_from_pc()
function (armlinux_breakpoint_from_pc() say) is needed, I would suggest
defining BREAKPOINT_FROM_PC as a global function pointer and initialize
that pointer in __initialize_arm_tdep().  The existing
arm_breakpoint_from_pc() function should not be #ifdef'd out.

In the future that global can be be made part of an architecture object
(``struct gdbarch'' say).


--


The file gdb/config/arm/tm-linux.h #defines OS_BKPT_SWI.  That is in
turn used by the ARM version of CALL_DUMMY.  CALL_DUMMY has just been
replaced with CALL_DUMMY_WORDS and SIZEOF_CALL_DUMMY_WORDS (see
gdb/doc/gdbint.texi in the *next* snapshot).  Rather than define
OS_BKPT_SWI could I strongly encourage you to instead use these new
macros.  Like for BREAKPOINT_FROM_PC, I would suggest using a global
initialized from __initialize_arm_tdep().


--


I'm slightly curious about what is going on with all these different
breakpoints (I should hasten to point out that I'm _not_ the ARM
expert/maintainer :-).  Stan Shebs recently commited the change:

	1999-03-02  Stan Shebs  <shebs@andros.cygnus.com>

	From Gary Thomas  <gthomas@cygnus.co.uk>:
	* arm-tdep.c (ARM_LE_BREAKPOINT, ARM_BE_BREAKPOINT,
	THUMB_LE_BREAKPOINT, THUMB_BE_BREAKPOINT): Use illegal instruction
	instead of SWI 24.
	* config/arm/tm-arm.h (CALL_DUMMY): Ditto.
	(IN_SIGTRAMP): Define.

Originally they were:

 ARM_LE_BREAKPOINT {0x00,0x00,0x18,0xef} /* BKPT_SWI from <sys/ptrace.h
*/
 ARM_BE_BREAKPOINT {0xef,0x18,0x00,0x00} /* BKPT_SWI from <sys/ptrace.h
*/

While Stan changed them to:

 ARM_LE_BREAKPOINT {0xFE,0xDE,0xFF,0xE7} /* Recognized illegal opcodes
*/
 ARM_BE_BREAKPOINT {0xE7,0xFF,0xDE,0xFE}

And now, in your patch there is:

 ARM_LE_BREAKPOINT        {0x01,0x00,0x9f,0xef}         /* swi 0x9f0001
*/
 ARM_BE_BREAKPOINT        {0xef,0x9f,0x00,0x01}

I'm just kind of wondering which/any are needed :-) There must be a
standard somewhere ;-)

Could I suggest including a comment explaining where your breakpoint
instructions come from.  If it is part of the LINUX/ARM environment then
make a reference to that.


	enjoy,
		Andrew