[ECOS] MIPS GDB Problems

[ECOS] MIPS GDB Problems

[Colin Spier]

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!

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

Re: [ECOS] MIPS GDB Problems

[Jonathan Larmour]

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

RE: [ECOS] MIPS GDB Problems

[Colin Spier]

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

Re: [ECOS] MIPS GDB Problems

[Jonathan Larmour]

Colin Spier wrote:
> 
> 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...

Sorry I assumed that's what you had been doing already. We've found it
certainly makes it easier to use the mips3 opcodes in the assembler, and
for gdb to grok that assembler. Although you can use .set mips3 directives
for that. But your way can work too.

> 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.

Try compiling with -ggdb or -gdwarf or -gdwarf-2. Sometimes that helps
although we've never needed it for mips targets in the past. Also if you've
written your own linker script, try discarding the .mdebug section. We've
found that helps.

Also try building without -ffunction-sections -fdata-sections in the
cflags, and -Wl,--gc-sections in the ldflags, as section garbage collection
has been known to interfere with debugging.

> 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?

I've done it with versions very close to the above, but not those very
versions other than gcc 2.95.2.

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

RE: [ECOS] MIPS GDB Problems

[Colin Spier]

Thanks for that - I built without -ffunction-sections -fdata-sections in the
cflags, and -Wl,--gc-sections in the ldflags and gdb now sees my source
code!

> -----Original Message-----
> From: jlarmour@redhat.com [ mailto:jlarmour@redhat.com]On Behalf Of
> Jonathan Larmour
> Sent: 28 November 2000 17:00
> To: Colin Spier
> Cc: Ecos-Discuss@Sourceware. Cygnus. Com
> Subject: Re: [ECOS] MIPS GDB Problems
>
>
> Colin Spier wrote:
> >
> > 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...
>
> Sorry I assumed that's what you had been doing already. We've found it
> certainly makes it easier to use the mips3 opcodes in the assembler, and
> for gdb to grok that assembler. Although you can use .set mips3 directives
> for that. But your way can work too.
>
> > 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.
>
> Try compiling with -ggdb or -gdwarf or -gdwarf-2. Sometimes that helps
> although we've never needed it for mips targets in the past. Also
> if you've
> written your own linker script, try discarding the .mdebug section. We've
> found that helps.
>
> Also try building without -ffunction-sections -fdata-sections in the
> cflags, and -Wl,--gc-sections in the ldflags, as section garbage
> collection
> has been known to interfere with debugging.
>
> > 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?
>
> I've done it with versions very close to the above, but not those very
> versions other than gcc 2.95.2.
>
> 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