This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
porting gdb to harvard architecture machine...
- From: Alan Lehotsky <alehotsky at me dot com>
- To: gdb at sourceware dot org
- Date: Sun, 24 Mar 2013 11:06:08 -0400
- Subject: porting gdb to harvard architecture machine...
- Reply-to: apl at alum dot mit dot edu
I've got an architecture with separate I/D spaces.
For my initial port of the binutils, I set up I space as having a LMA and VMA at 0x20000000 so that it didn't overlap with the data memory addresses. Using this, i had a complete tool chain (including a simulator and gdb) pretty much working - only about 600 tests failing in gdb and under 150 failures in the gcc tests.
But that results in problems with pointer arithmetic (pointers are actually only 21 bits, but the linker stores 32 bits for relocatable addresses) so static pointers don't compare as equal to dynamic pointers
By changing the linker script to have a LMA of 0x20000000 and a VMA of 0x0, the arithmetic problems go away and the gcc test suite and simulator run fine , but gdb falls over dead on nearly every interesting test - completely unable to resolve symbolic addresses or find any of the debug info.
Do I need to change the output section descriptions for the debug sections somehow? Or is gdb just completely unhappy about this kind of code and data memory aliasing?
How is what I've done different from overlay support? If I go back and restructure my linker map as if I was using overlays is that likely to work?