Hi,
On 25.9.2024 0.09, Andreas Schwab wrote:
On Sep 24 2024, Eero Tamminen wrote:
On 24.9.2024 4.03, Michael Schmitz wrote:
On 23/09/24 09:48, Eero Tamminen wrote:
Not having it configured, but crash backtraces going through its IRQ
handling code, is confusing (found while debugging issues in Atari
I don't see how backtraces could go through the EtherNAT interrupt code
- the interrupt only gets enabled if the hardware has been detected.
Maybe you meant you see the generic IRQ handling code called for the
EtherNAT's interrupt controller?
It was many years ago, but I _did_ see one of these functions in Hatari
debugger's backtrace, although I had explicitly disabled EtherNAT support.
That can easily happen if a word on the stack happens to match the
address range of an unrelated function.
Hatari debugger backtrace does not rely on frame pointers or stack
content unwinding, i.e. it's immune to stack corruption.
Backtrace is a by-product of Hatari profiler, which tracks every
emulated (CPU & DSP) instruction and constructs call-graph while the
code runs, by comparing PC register values against function addresses.
---
LILO functionality in Hatari reads function addresses from the
(specified) "Symbol.map" file (in addition to starting kernel). After
typing "profile on" in debugger, one sees backtrace every time debugger
is invoked.
(To trace all kernel function calls, one can use Hatari "--trace
cpu_symbols" option, which can be toggled in the debugger, either
manually, or automatically by a breakpoint. To trace a subset of the
function calls, one can remove others from the "Symbols.map" file.)
- Eero
PS. To do similar instruction tracking for PCs would need special data
collection HW and offline data processing (ARM ETM [1] & Intel PTI [2]),
but when emulating old/slow m68k machines, it can all be done in SW at
real-time.
[1]
https://developer.arm.com/documentation/ddi0488/h/embedded-trace-macrocell/about-etm
[2] https://lldb.llvm.org/use/intel_pt.html
