This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

porting gdb to harvard architecture machine...


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]