[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
>
+ssize_t
+_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.
Regards,
Michael
Other related posts:
