| Re: [hatari-devel] NetBSD loader for Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 24.7.2022 19.37, Thorsten Otto wrote:
On Sonntag, 24. Juli 2022 18:10:41 CEST Eero Tamminen wrote:
I think elf.h stuff
could be split to a common header, instead of being inlined to both
loader files.
Yes, maybe. I did this already for ARAnyM, too.
There's code that stuffs data to "symtab", but that does not appear to
be used anywhere?
That is used by the kernel. [explanation...]
Thanks!
no checks whether that is valid memory range (= is there
enough RAM for it)?
There is a check for this, after calculating the symbol size.
Ok, found it now.
It would be great if symbol data would work
Yes, i know. Shouldn't be too hard, since the kernel is already in memory.
Just have to watch out for the values; as already said, the kernel moves
itself in memory before doing anything else, and possibly moves itself again
to TT-RAM.
In Linux case, Hatari debugger shows correct (physical) addresses only
when kernel is loaded to ST-RAM. I think this is related to MMU memory
mappings.
> Only issue would be that the debugger symbol command needs a
filename, so you may have to write the map to a temporary file.
Creating temp files is not really palatable.
I think better would be to:
* move symbol_t struct definition from symbol-common.c to symbols.h
* create array of those directly in netbsd.c
* give that to new function in symbols.c that creates "symbol_list_t
*CpuSymbolsList" [1] from the given array:
Symbols_Set(symbol_t *symbols, int count)
[1] with separate symbol arrays for symbols sorted by name, and by
address, created and trimmed from the original list.
Which of the things discussed here you would be interested to do?
(I can do some, but I do not have much time currently, so it would not
be fast.)
- Eero