On Sunday 07 September 2014 16:03:53 Arun Sharma wrote: > 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.
Hey Arun, yes, that's the one. Please push it - many thanks. Bye > 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=package > >> s/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=d04d > >> > c94 > >> > 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 -- Milian Wolff [email protected] http://milianw.de _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
