backtrace() on mips seems to always return 1 on mips/glibc (I tried with buildroot, debian stable and debian testing), which renders it useless and breaks a RELEASE_ASSERT in StackTrace::captureStackTrace().
Created attachment 379535 [details] Patch Patch implementing this.
I have not checked glibc's code, but I expect that for code built without frame pointers (the default for MIPS) it's always returning an error because it's hard to walk the stack otherwise. For binaries with .eh_frame sections, libunwind should work, but that would still require building passing “-fasynchronous-unwind-tables” to GCC. That might be an option if we want to bring back support for backtraces on MIPS at some point. Therefore, the patch is r=me, because plain backtrace() will be useless 99% of the time for MIPS.
Comment on attachment 379535 [details] Patch Clearing flags on attachment: 379535 Committed r250516: <https://trac.webkit.org/changeset/250516>
All reviewed patches have been landed. Closing bug.
<rdar://problem/55835215>
(In reply to Adrian Perez from comment #2) > I have not checked glibc's code, but I expect that for code built > without frame pointers (the default for MIPS) it's always returning > an error because it's hard to walk the stack otherwise. > > For binaries with .eh_frame sections, libunwind should work, but that > would still require building passing “-fasynchronous-unwind-tables” > to GCC. That might be an option if we want to bring back support for > backtraces on MIPS at some point. > > Therefore, the patch is r=me, because plain backtrace() will be useless > 99% of the time for MIPS. Thanks for explaining the reasons behind backtrace() being useless on MIPS. Note that technically, it's not returning an error (AFAIK the backtrace()'s API does not allow for that), but it's just giving a stack trace of size one (the current function), which confuses WTF code (even though it has code to ignore backtrace() if it returns 0, a return of 1 is not an expected failure case).