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]

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


I have finished merging the ARM code.  It will require another round of
patches to fix a few warts, but I would appreciate having it looked at. 
It has regressed a little from my previous version, but I'm almost back
to where I was.  I've attached a patch, and placed a tarball of the
source on at:

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

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.

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.

I have compiled, linked, and run the testsuite for GDB successfully for
build = host = target=arm-unknown-linux-gnu.

               === gdb Summary ===

# of expected passes            6009
# of unexpected failures        48
# of unexpected successes       2
# of expected failures          195
# of unresolved testcases       3

I have compiled and linked for GDB successfully for:

	build=host=arm-unknown-linux-gnu, target=arm-elf
	build=host=arm-unknown-linux-gnu, target=arm-coff

	build=host=i586-pc-linux-gnu, target=arm-unknown-linux-gnu.
	build=host=i586-pc-linux-gnu, target=arm-elf
	build=host=i586-pc-linux-gnu, target=arm-coff

This verifies there are no outstanding syntax errors or unresolved
externals at least.  The testsuite fails in all cases due to the lack of
suitable cross compilers and target hardware.  I don't believe I will be
able to run the testsuites successfully for the embedded targets. 
The x86 builds wouldn't compile correctly due to the implementations of
convert_from_extended(), convert_to_extended().  I have ifdef'd them out
ATM, and replaced them with stubs, until I can resolve the problems.

I don't have suitable environments to test:



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.

Thread support:
This has been waiting for Cygnus to integrate the threading patches, so
I don't redo their efforts.

Multi-arch readiness:
	1) Remove EXTRA_FRAME_INFO.  
	3) Convert REGISTER_NAME to a function.
	4) Convert to new CALL_DUMMY scheme.
	5) Verify functions maintain name space purity.

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:

Consider the following code and the generated instructions:

1       int foo (int a)
2       {
3         int b;
5         if (a == 3)
6           b = 10;
7         else
8           b = 20;
10        return b;
11      }

00000000 <foo>:
   0:   e1a0c00d        mov     ip, sp
   4:   e92dd800        stmdb   sp!, {fp, ip, lr, pc}
   8:   e24cb004        sub     fp, ip, #4
   c:   e3500003        cmp     r0, #3
  10:   13a00014        movne   r0, #20
  14:   03a0000a        moveq   r0, #10
  18:   e91ba800        ldmdb   fp, {fp, sp, pc}

The ARM uses a predicated instruction set (the condition in which it
will execute is an integral part of the instruction; in the case of the
ARM, the 4 most significant bits) which allows the following code:

   c:   e3500003        cmp     r0, #3
  10:   13a00014        movne   r0, #20
  14:   03a0000a        moveq   r0, #10

In the current scheme in GDB, "break 6" will set a breakpoint on line 6
of the C code.  This corresponds to the instruction at address 14: being
replaced by the breakpoint instruction.  Unfortunately it means that GDB
stops at line 6 on the ARM all the time, even when a != 3.

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.

This will present a problem for single stepping, particularly with
stepping using undefined instructions as breakpoints.  What happens if
the target of the step is an instruction that is not going to be
executed due to its condition failing.

Another problem is semantic.  The user types "break 0x10" to break at
address 10.  If I am looking at an assembly dump I usually want the
breakpoint to be unconditional.  This could lead to unexpected results
for the user.


Scott Bambrough - Software Engineer


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