2015-04-11 19:28 GMT+02:00 Michael Lotz <mmlr@xxxxxxxx>:
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
