You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is currently very hard to get stacktraces, as %si and %di can be pushed before %bp. I suggest to push %bp first, so that getting the return address of the function gets easier.
Thank you,
Azhagen
The text was updated successfully, but these errors were encountered:
Yes, it can be hard to determine a function start address when running code without a symbol table and/or compiled without certain compiler options. I ended up writing a full stack backtrace set of functions that allow displaying stack traces both with and without symbol tables (See screenshot in ghaerr/elks#1843). In the case of no symbol table, the _get_fn_start_address function reads the instruction stream backwards, recognizing all ia16-elf-gcc generated function prologues full list shown here and returns a function start address at runtime. See also Stack backtrace in C library and Enable symbolic debugging.
I'm not sure exactly the problem you are trying to solve, but for stack backtraces to always work the -fno-omit-frame-pointer and -fno-optimize-sibling-calls compiler options should be set so that full proper function prologues are always generated. If a function needs to know its return (IP) address or frame (BP) address it can call __builtin_return_address(0) or __builtin_frame_address(0) respectively.
Hello,
It is currently very hard to get stacktraces, as %si and %di can be pushed before %bp. I suggest to push %bp first, so that getting the return address of the function gets easier.
Thank you,
Azhagen
The text was updated successfully, but these errors were encountered: