Vivek Goyal wrote: > > > > > > > Hi Dave, > > > > > > Why to go for this approach? Does it give better backtraces as compared > > > to retrieving the information from kernel vmlinux (unwind info) or > > > from debug sections? > > > > > > > Why go for this approach? Because it works? > > > > I don't understand what you mean by "Does it give better backtraces as > > compared to..." What are you talking about -- compared to what? > > > > I was referring to Rachita's implementation of doing backtraces using > .eh_frame section info. > Right... and that's what I was referring to below -- which unfortunately never became an "implementation". > > > The initial attempt to use the unwind/debug data was never accomplished, > > and then the rug was pulled when CONFIG_UNWIND_INFO was de-configured > > from the kernel, leaving the kernel being built with -fno-asynchronous-unwind-tables > > and the vmlinux .eh_frame section discarded. > > Hm..., So no .eh_frame now in RHEL kernels. I remember that previously we > had discussed the approach of parsing .debuginfo or similar section generated > by gcc. I am not sure what -fno-asynchronous-unwind-tables does. Does not > generate unwind tables? Does that mean now there is no way of doing backtraces > looking at .dwarf debuginfo? But there has to be one as gdb does it. Hmm.... As has always been the case, if and when you guys figure it out how to do it, by all means send me a patch for an alternate mechanism that can cover all configuration bases, doesn't require an ELF format dumpfile, doesn't abort when it bumps into an exception frame, can switch between the 3 types of kernel stacks, etc... Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
