| Re: [hatari-devel] Feature idea/question: primitive memory manager |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 1.1.2024 18.06, Nicolas Pomarède wrote:
Le 01/01/2024 à 15:42, Miro Kropáček a écrit :
On Mon, 1 Jan 2024 at 15:32, Thomas Huth <th.huth@xxxxxxxxx
<mailto:th.huth@xxxxxxxxx>> wrote:
Programs also access memory outside of the above list, like pointers
in the cookie jar, the buffer returned by the Iorec XBIOS function,
etc. ... so maybe it's possible to implement such a feature, but
it's certainly a lot of work to get that really right.
Good point. However that's exactly the thing -- we don't have to get
it really right. It could be just a warning in the console. So if I,
as a developer, see that 0x000005a0 is being accessed "illegally", I
can safely ignore that warning and continue my work.
This is meant to be purely a developer's tool, nothing for regular
users (it would be disabled by default).
also consider that when using 68030 + MMU, the TOS mmu tables are
located in the ram below 0x10000, so you will get tons of such warnings.
I think that to make such an option viable you would need to combine it
with only certains PC values (for example don't report anything when PC
is somewhere in TOS ROM)
That can be worked around by the enable option taking e.g. a name of a
file listing address ranges that this check should be ignored (in
addition to program's own memory and IO regs).
In minimal Hatari test environment addresses of such things should be
fairly stable, so developer can fill that file incrementally.
I'm more concerned about the general usefulness of such feature for
tracking memory access issues though.
I think most invalid memory access issues happen within memory that
program *has* allocated from TOS, and which e.g. libc malloc etc. is
providing the app in smaller pieces, and application corrupting those
internal data structures with some off-by-one write. I.e. something
that this feature would not detect. [1]
Also, if _one runs program in just-enough amount of RAM required for
program to function_, program trying to write outside the memory areas
it has requested from TOS, in most cases already causes an exception
immediately:
- Using offset to a NULL pointer i.e. low address
- Pointer going outside of RAM
I think the other relevant memory areas (not belonging to the program)
are mostly just TOS internal allocations at lower addresses, and screen
buffer in ST-RAM. As one should see invalid writes to screen, main
issue this feature would catch, could be "just" writing over some of the
TOS allocations at lower memory addresses.
(On Hatari side, catching these would require possibility to set memory
write breakpoints which Nicolas has been "promising" now and then.)
[1] to catch those, besides tracking memory writes, one needs something
tracking all libraries alloc & free functions, like Linux tools do.
Because Atari uses static linking, tracking them would require
application to be built with symbols, in addition the tracking
functionality needing to know what value(s) to track from each alloc
function, and how to match them to correct free function.
It would also have same problems as what Miro's original suggestion has,
of Atari programs doing also a lot of other memory accesses...
If that program runs also on Linux, I would do such debugging there,
with Valgrind, DUMA and ASAN:
https://valgrind.org/info/tools.html#memcheck
https://github.com/johnsonjh/duma#description
https://github.com/google/sanitizers/wiki/AddressSanitizer
Btw. ASAN overhead is nowadays surprisingly small. IMHO best native
option would be to get "-fsanitize=address" working with latest m68k
GCC. It might even be possible to speed it up with NativeFeatures.
- Eero
PS. I wonder would it be possible for EmuTOS to use MMU to protect its
own and program's allocations? Protecting latter would mean adding
guard pages around all allocations that would trigger exception both on
write & read, like DUMA does.
It could be separate (much slower) build of EmuTOS...