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

[James Ingham <jingham at cygnus dot com>]

Scott,

I will check these out give them a whirl, and get back to you as
soon as I can.  I am excruciatingly busy right now, but this is a high 
priority for me so I will get to it as soon as I can, with lots of
apologies up front for not being as prompt as I would like.

Thanks for doing all this!

Jim

 > Jim,
 > 
 > 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 netwinder.org at:
 > 
 > ftp://ftp.netwinder.org/users/s/scottb/gdb-991103.tar.gz
 > 
 > I've made two targets in the configure scripts for ARM: linux and
 > embedded.  Basically I have:
 > 
 > in gdb/config/arm:
 > 
 > embed.mh, embed.mt, nm-embed.h, tm-embed.h, xm-embed.h
 > linux.mh, linux.mt, nm-linux.h, tm-linux.h, xm-linux.h
 > tm-arm.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
 > necessary.
 > 
 > 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:
 > 
 > 	build=host=sparc-sun-solaris2.5
 > 	build=host=i686-cygwin32
 > 
 > TO DO:
 > 
 > 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.  
 > 	2) Replace FRAME_FIND_SAVED_REGS with FRAME_INIT_SAVED_REGS.
 > 	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
 > correctness.
 > 
 > Breakpoints:
 > 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;
 > 4       
 > 5         if (a == 3)
 > 6           b = 10;
 > 7         else
 > 8           b = 20;
 > 9
 > 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
 > 
 > -- 
 > Scott Bambrough - Software Engineer
 > REBEL.COM    http://www.rebel.com
 > NetWinder    http://www.netwinder.org

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions Inc.