[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

Hi Axel

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: