mb-gdb: problem simulating memory mapped i/o devices

Hello,

I'm trying to simulate a C program in MB-GDB but I get trouble when
trying to simulate memory based I/O devices.


I'm not using Microblaze but a improved Openfire core (same ISA) so
microblaze toolchain is working for me (I also modified some TCL
script inside mb-gdb in order to use the gdb's microblaze simulator
instead of XMD).


Seems that GDB marks or initialize only memory regions defined in the
executabe program(sections .text, .rodata, .data, etc..) and when my
program tries to access the memory area where I/O devices are mapped
(outside .text, .data, etc. regions), GDB raises SIGSEGV
(segmentation
violations signals).


example:


led_status = *(char *) IODEVICE_LEDS;    // IODEVICES start at
0x80000000 but program resides from 0x0 to 0x1000


A solution I found is to define the IO device memory area at the end
of the linker script and initialize it with some data.


 . = _IO_START_ADDR;
 _iospace : {
   . = _IO_SIZE;
 }


This seems to work more or less but I need to execute the program
with
breakpoints and manually set / read the values of such memory
positions in order to simulate the device behaviour.


The question is:


Is there any way in GDB to map a memory location (8, 16 o 32 bit
size)
to a file for input or output (this is, every time I read[write] from
such memory location, the value is readed[writed] from[to] a file ?


Is also possible to use an script connected to such memory location
(for example interactively controlling the position of switches or
so).


Thank you very much for your help
Manuel

manuel-lozano@mixmail.com wrote:
> Is there any way in GDB to map a memory location (8, 16 o
> 32 bit size) to a file for input or output (this is,
> every time I read[write] from such memory location, the
> value is readed[writed] from[to] a file ?

This is more of a problem with the simulator than
with GDB itself. In my experience, most of the
simulators that come with GDB seem to be intended
to exercise code produced by GCC as a means of
running test cases, and not as a means to simulate
an embedded system. In fact, this is true of most
of the simulators that I have worked with, an exception
being simulavrxx.

> Is also possible to use an script connected to such
> memory location (for example interactively controlling
> the position of switches or so).

Simulating hardware devices *can* be done if you have
the source code, the time and the inclination.
Good luck.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1