URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [gnu-stable/] [gdb-7.2/] [sim/] [ppc/] [BUGS] - Rev 841
Compare with Previous | Blame | View Log
ChangeLog
See the ChangeLog file looking for lines taged with the word FIXME.
COREFILE.C:
The implementation of corefile.c (defined by corefile.h) isn't the
best. It is intended to be functionaly correct rather than fast. One
option being considered is to add a data cache to reduce the overhead
of the most common case of data read/writes.
VEA:
Missing VEA system calls.
ppc-instructions:
Missing or commented out instructions.
64bit:
64bit target untested. 64bit host broken. For instance use of scanf
"%x", &long long.
hw_*.c:
Better and more devices.
PORTABILITY:
(Notes taken from Michael Meissner): Heavy use of the ## operator -
fix using the clasic X/**/Y hack; Use of the signed keyword. In
particular, signed char has no analogue in classic C (though most
implementations of classic C use signed chars); Use of long long which
restricts the target compiler to be GCC.
TRACING:
debug.c: Macro's should be extended to include:
IS_*TRACE: True if tracing enabled
*TRACE_PREFIX: Outputs just the prefix line
hw_trace.c: Flush, replace with a psim_set_tracing or some
such program.
CIA/NIA:
Replace with functions to return/increment the CIA?
SMP & GDB:
GDB doesn't understand SMP!
OVERALL STRUCTURE:
A new file pstruct.h is to be created that contains a single flat data
structure containing:
pstruct {
events;
core;
processor[nr_cpus];
monitor;
devices;
trace;
}
The CPU's structure, in turn would contain the VM sub structures.
When SMP==0, everything would have PSTRUCT passed. In SMP mode,
however, there are two choices: PSTRUCT + CPU_NR or PROCESSOR. I
suspect the latter is better.
It is believed that this would significantly improve performance (at
the price of reduced control over object scope).
IGEN:
Igen at present can't do the following:
o duplication is an all or nothing afair.
It should be configurable according to
the instruction or the sub-table.
o Due to the naming, only a single generated
simulator can be included in a program.
IGEN should be able to generate multiple
engines that can all be included in a program
o handle alternate architectures.
o Igen should support the generation of a
disasembler and posibly an assembler.
I suggest that the table be extended to
include, for each instruction, additional
lines describing the extual format of the
instruction.
One possible format is:
"mtlr %RS":SPR.something
"mtspr %SPR, %RS"