[haiku-commits] Re: haiku: hrev49020 - src/system/libroot/posix/malloc_debug src/system/kernel src/system/kernel/debug headers/private/system headers/private/kernel
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 11 Apr 2015 11:34:04 +0200
On 10.04.2015 21:11, Axel Dörfler wrote:
Am 10/04/2015 um 17:29 schrieb mmlr@xxxxxxxx:
This is meant to be used in situations where more elaborate stack
generation, like done in the userland debugging helpers, is not
due to constraints.
Is there any reason to have a syscall for this? Getting the stack is
architecture dependent, but usually rather trivial (at least when there
is proper framing).
Convenience and prior knowledge mostly. I looked into the userland
debug_support functions which also provide this, but these are not
available from libroot and at least the symbol lookup uses the heap, so
isn't an option.
Since I already worked with the kernel debugger facilities, I knew that
the exact thing I needed was already there and figured rather expose and
use that instead of cooking up yet another version. In hindsight it
might have been a better idea to reuse the debug_support code instead of
using a syscall. I will look into that for the stack trace generation.
In any case, the runtime loader already has symbol lookup facilities,
why not use those?
Indeed, I overlooked the get_nearest_symbol_at_address function as I
only looked in elf_symbol_lookup.cpp where only the other lookup (symbol
-> address) is implemented. I've extended the function to provide all
the needed arguments, switched the guarded_heap to use it and removed
the lookup_symbol syscall in hrev49025. The lookup overhead shrank
considerably. Unfortunately the lookup is as basic as the one from the
kernel debugger, so no lookup of static functions there either.
Other related posts: