From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Colin Spier" <Colin.Spier@pipinghotnetworks.com>
To: "Jonathan Larmour" <jlarmour@cygnus.co.uk>
Cc: "Ecos-Discuss@Sourceware. Cygnus. Com" <ecos-discuss@sourceware.cygnus.com>
Subject: RE: [ECOS] MIPS GDB Problems
Date: Tue, 28 Nov 2000 09:38:00 -0000
Message-id: <NDBBLCPHGLOPOCELHCIHGEDMCCAA.Colin.Spier@pipinghotnetworks.com>
References: <3A23E499.597FCB18@cygnus.co.uk>
X-SW-Source: 2000-11/msg00357.html

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