From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Colin Spier" To: "Ecos-Discuss@Sourceware. Cygnus. Com" Subject: RE: [ECOS] MIPS GDB Problems Date: Tue, 28 Nov 2000 06:29:00 -0000 Message-id: References: <3A22A099.9FC8E4B6@cygnus.co.uk> X-SW-Source: 2000-11/msg00346.html If I set up the stub code as you suggest, gdb does not communicate with the target unless I rebuild it (gdb) for mips64-elf. Unfortunately, this still doesn't help... Further investigation shows that, even before connecting to the target (i.e. without using the stub), 'info address _start' returns "0x80028000" which is correct. 'info address __warm_start' returns "0x80028128" which again I believe. However, 'info address reset_vector' returns "0x80028000" when I was expecting 0x800001a4 and 'info address main' returns "0x0"! I tried rebuilding the entire mips gnu toolchain for mips64-elf, and then built eCos and my source file (which contains a very simple 'main' that just switches an LED on and calls 'breakpoint()') with no -mcpu= or -mips directives, and gdb still thinks that the address of main is 0x0. I've looked at the assembly code produced by gcc for the source file containing my 'main' function, and it definitely contains stabs information. However, 'mips-elf-objdump --debugging' states that the executable file contains "no recognized debugging information". Despite this, when in graphical mode, gdb does appear to realise which lines of my 'main' function are actually executable code, and those are the only lines at which it will attempt to instantiate a breakpoint... Has anyone successfully used this toolchain (binutils 2.10.1, gcc 2.95.2, insight 5.0) to provide a debugging capability on mips? Should I have applied any patches? Alternatively, are there any other toolchain recommendations? Thanks, Colin. -- Colin Spier PipingHot Networks Ltd. Office: +44 (0)1364 655500 DDI: +44 (0)1364 655521 Fax: +44 (0)1364 654625 mailto:colin.spier@pipinghotnetworks.com http://www.pipinghotnetworks.com > -----Original Message----- > From: jlarmour@redhat.com [ mailto:jlarmour@redhat.com]On Behalf Of > Jonathan Larmour > Sent: 27 November 2000 17:58 > To: Colin Spier > Cc: Ecos-Discuss@Sourceware. Cygnus. Com > Subject: Re: [ECOS] MIPS GDB Problems > > > Colin Spier wrote: > > > > Hi, > > > > I'm trying to use eCos with a slightly unusual MIPS chip (I'm compiling > > with -mcpu=r4000 -mips2). I'm using a GNU toolchain (binutils > 2.10.1, gcc > > 2.95.2 and insight 5.0) built for mips-elf (I had to make some slight > > changes to the gcc makefile so that I can use -mips2) > > > > I've built with '-g' and located my code at 0x80000000. It > runs OK, but GDB > > can't find the code... > > > > If I try 'list main' then it lists the 'abort' code. > Similarly, if I try > > 'list breakpoint' it also lists the 'abort' code! If I single step > > assembler instructions then gdb complains, e.g. "Warning: GDB > can't find the > > start of the function at 0x8003c50c" > > > > I wonder if this is because the address has been sign extended. > > mips-elf-objdump shows the code starting at 0xffffffff80000000. > Similarly, > > if I have a 'main' function at 0x80028644 then if I try to 'disassemble > > 0x80028644' gdb says "No function contains specified address". > However, if > > I 'disassemble 0xffffffff80028644' then this shows the assembly > code for my > > main function. > > > > All suggestions as to how I can get gdb to see my source are welcome! > > It sounds like one of two problems: > > - either GDB does not think it is working with a 32-bit target > (i.e. as per > -mips2). Try using "set archdebug 1" at the start of your GDB session to > see what GDB really thinks. > > - The alternative is that you haven't set your stub code up quite right. > You will need to be using anon cvs for a start. Then in > hal/mips/arch/current/include/mips-stub.h you need to ensure that > REGSIZE(X) is 8, target_register_t is unsigned long, and > CYGARC_SIGN_EXTEND_REGISTERS is set. > > Jifl > -- > Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 > (1223) 728762 > "Plan to be spontaneous tomorrow." || These opinions are all my > own fault