[ECOS] mips64vr4300 gdb-stub problem

Jonathan Larmour jlarmour@redhat.co.uk
Thu Apr 27 09:29:00 GMT 2000

charles wrote:
> From: charles <root@>
> To: ecos-discuss@sourceware.cygnus.com
> Date: Fri, 14 Apr 2000 17:19:10 +0800
> Subject: [ECOS] mips64vr4300 gdb-stub problem
> Hi, all. I've successfully built the Gnu tools for mipsvr4300 and the tests(  in Nt4.0). And I can download the executable file to the 4373 board with the gdb stub, but  I can't get the correct result, it seems that the program keeps running, without stop. The following information is result I get, any help is appreciated, thank you!
> /////////////////////////////////////////
> bash-2.02$ mips64vr4300-elf-gdb -nw thread_gdb.exe
> GNU gdb 20000314
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-cygwin --target=mips64vr4300-elf"...
> (gdb) set remotebaud 38400
> (gdb) set mips-force-32bit-saved-gpregs
> (gdb) target remote com1
> Remote debugging using com1
> 0xbfc04550 in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0xb4 lma 0x80100000
> Loading section .text, size 0x6684 lma 0x801000b4
> Loading section .ctors, size 0x18 lma 0x80106738
> Loading section .dtors, size 0x8 lma 0x80106750
> Loading section .rodata, size 0x57c lma 0x80106758
> Loading section .data, size 0x5d4 lma 0x80106ce0
> Start address 0x801000a4 , load size 29352
> Transfer rate: 26090 bits/sec, 481 bytes/write.
> (gdb) continue
> Continuing.

People have already commented that gcc snapshots seem to be having trouble
with 64-bit MIPS targets - that's probably what's going on here. All I can
suggest you do is try to debug this. Try setting a breakpoint somewhere
early in the startup, like cyg_hal_invoke_constructors, and single-step
from there. To do this effectively you should build your own thread_gdb -
in fact any test application will do - so that debugging information is
included in your executable. Preferably also try out with optimization
disabled - i.e. with -O2 in the build flags removed.

The likely problem is some miscompilation, so the assembler will not match
the C code. Sorry I can't be more helpful :-(.
> After some time, I reset the target, I get the follwoing information
> ////////////
> Program received signal SIGTRAP, Trace/breakpoint trap.
> warning: Warning: GDB can't find the start of the function at 0xbfc04550.

When you reset the target, the program in the boot ROM image deliberately
hits a breakpoint. Because this breakpoint isn't one that GDB itself set,
it reports this message. So this is expected if you reset the target.

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

More information about the Ecos-discuss mailing list