This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


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

RE: MIPS GDB Problems


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


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