Just to confirm: is this the patch you're referring to? http://paste.ubuntu.com/8278768/
Doesn't break anything on my end. I'll push it once you confirm. -Arun On Mon, Aug 25, 2014 at 4:41 PM, Milian Wolff <[email protected]> wrote: > On Monday 25 August 2014 11:46:12 Milian Wolff wrote: >> On Thursday 19 June 2014 23:50:25 Lassi Tuura wrote: >> > Hey, >> >> Hey Lassi, Arun. >> >> I want to revive this thread after my long absence in the hope to get the >> situation improved upstream. Locally, I've been running with the patch of >> the previous mail for some time now and it works very well in my case. >> > Thanks for testing that. Note though that as the comment immediately above >> > says, x86_64 ABI says the last frame should have null RBP (IIRC, that's >> > 3.4.1 Initial Stack and Register State). Can you possibly find out why >> > that doesn't hold on your platform? >> >> Do you have any suggestions on how to do that? I.e. what should I look at? >> Specific compile options for libc? You can find the PKGBUILD that is used on >> ArchLinux here: >> >> https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/g >> libc >> >> That contains the configure invocation with all its arguments and the >> patches that are applied previously. >> >> > The code I was thinking about is apply_reg_state in src/dwarf/Gparser.c >> > where the DWARF_IS_NULL_LOC (c->loc[c->ret_addr_column]) conditions should >> > have kicked in to set RIP for the next step to 0, which I vaguely recall >> > caused the unwind to terminate at that step. But maybe there was a change >> > to allow unwinding to continue with RIP == 0. (Arun do you recall details >> > on that? For example >> > http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commitdiff;h=d04dc94 >> > cc 2b0141f06ed9de1665ab89a3f549e0b - I vaguely recall we talked about it.) >> >> Any news on that Arun? I'll also try to figure out whats going on and why >> this is not kicking in. > > Quick update, I looked at it a bit more with the following test program: > > ~~~~~~~~~~~~~~~~ > #include <stdio.h> > > #define UNW_LOCAL_ONLY > #include <libunwind.h> > > int main() > { > const int MAX_SIZE = 128; > void* data[MAX_SIZE]; > for (int repeat = 0; repeat < 2; ++repeat) { > int size = unw_backtrace(data, MAX_SIZE); > printf("\ntrace size: %d\n\n", size); > for (int i = 0; i < size; ++i) { > printf("%p\n", data[i]); > } > printf("\n"); > } > return 0; > } > ~~~~~~~~~~~~~~~~ > > Running it with UNW_DEBUG_LEVEL=15 env var set, I get the output you find > attached in original.log. I've added debug output to apply_reg_state when the > IP set set to zero, i.e.: apply_reg_state:818: SETTING IP TO ZERO > > You'll see that the IP _is_ set to zero but unwinding is continued thereafter, > even though "DWARF spec says undefined return address location means end of > stack." (dwarf/Gparser.c). The garbage "0" ip is returned at the end. > > With the patch to also check for this in x86_64/Gstep.c applied, the output > changes to patched.log and everything behaves correctly, as far as I can see. > The garbage "0" ip is skipped, i.e. unwind stops properly and everything is > cached and fast. > > So, can we get this patch in, or should we add a "last_frame" to dwarf_cursor > which is set to 1 when the return address location is undefined? This would > mean changes all over the place though, something which I'd not be comfortable > with as I cannot test other architectures easily. Esp. the question whether > checking for ip == 0 is valid on e.g. x86 or not is something I cannot decide. > > Bye > -- > Milian Wolff > [email protected] > http://milianw.de > > _______________________________________________ > Libunwind-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/libunwind-devel > _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
