This is the mail archive of the ecos-discuss@sourceware.cygnus.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: mips64vr4300 gdb-stub problem


charles wrote:
> 
> From: charles <root@202.96.178.16>
> 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.

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]