[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 19:28:00 +0200

On 11.04.2015 16:39, Paweł Dziepak wrote:

2015-04-10 17:29 GMT+02:00 <mmlr@xxxxxxxx <mailto:mmlr@xxxxxxxx>>:

Commit: b959d46dbd2f9087ae860dbced40440c28596a6e
+_user_get_stack_trace(size_t addressCount, addr_t* userReturnAddresses)
+ addr_t returnAddresses[addressCount];

void enter_kdl()
_kern_get_stack_trace(-1, nullptr);
// VLAs are evil

Indeed. This one is actually a case for the code quality discussion. The lack of bounds checks and imposing an upper bound in the first place is indeed a careless oversight on my part.

Besides, I don't think there is any reason why we need to involve kernel
in order to get stack trace, unless we want to try some kind of new
"mega-monolithic" kernel architecture where even parts of user libraries
are running in kernel mode ;)

As already stated in the reply to Axel, this was introduced mostly due to convenience. To my knowledge there is no way to get a stack trace in userland that is ready to use in this situation.

The debug_support code used by the Debugger on the other hand uses the kernel user debugger features to get its work done. This makes sense for Debugger as it is always debugging another team and has to read foreign memory to do its job. Reusing that code here would however not reduce the amount of syscalls due to the port communication and using the kernel to read ones own stack isn't better than the get_stack_trace syscall.

Ultimately I guess I'll wind up porting over the kernel version to get the stack trace (or look into _Unwind_Backtrace) and put it into libroot. There's backtrace() and backtrace_symbols() that glibc provides which could be provided under Haiku that way as an added bonus.


Other related posts: