Re: frame unwinding patches
> I do agree with Jan that frame pointer unwinding is notoriously > untrustworthy. Even with some sanity checks it is hard to know whether > you are doing a correct unwind. gdb gets away with it through pretty > advanced frame sniffers, which take a lot of low-level compiler > generation knowledge to get correct (and even then...). You only restore > the pc, stack and frame pointer registers (maybe incorrectly). So > afterwards, even if you got valid CFI data you might be stuck. Yes, especially with mixed stack traces, where part of the stack has CFI and part of it doesn't, we quickly run into guesswork. I've regenerated the binaries as suggested, with the result being that raise() from libc actually has CFI, but doesn't set a frame pointer. So, the frame pointer unwinder can find raise() in the link register, but it sets up the FP register with the wrong value. Then raise() is unwound using CFI, which mixes up the registers some more. At that point we're lost. I don't see an easy way out of this. I will keep a version of the frame unwinding for perfparser as it's still better than not unwinding at all, but I do understand that it's not really suitable for mainline elfutils. br, Ulf
[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #8 from Mark Wielaard --- Please post how exactly you are configuring the build, compiler (version) and flags used. It would certainly help to have a concrete patch against current git. -- You are receiving this mail because: You are on the CC list for the bug.
Re: dwfl_attach_state alternative taking Ebl?
On Wed, 2017-04-05 at 15:04 +0200, Milian Wolff wrote: > On Wednesday, April 5, 2017 2:46:34 PM CEST Mark Wielaard wrote: > > On Thu, 2017-03-30 at 13:14 +0200, Milian Wolff wrote: > > > > OK. How do you know the Elf architecture in that case? How and by what > > > > is it given? Is that an EM constant or some architecture string? > > > > > > In our case we either get it from perf, or the user specifies it directly > > > on the command line. In both cases it is a string like "x86_64", "arm" or > > > "aarch64". We map that to a list of architectures we know about, see > > > e.g.: > > > > > > http://code.qt.io/cgit/qt-creator/perfparser.git/tree/app/ > > > perfregisterinfo.h#n29 > > > > > > So, any API that would allow us to map these architectures directly to a > > > dwfl/ elf counterpart would simplify our code, or at least would make it > > > easier to understand, as we wouldn't have to wait for an Elf file we can > > > open before calling dwfl_attach_state. > > > > So you map from simple architecture name like "x86" or "powerpc". But > > what mechanism do you have to whether that is 32 or 64 bit, and big or > > little endian? > > As Ulf said, we can add the required mappings. So from my side, I guess your > approach with the three machine/class/data constants would be a good > improvement already. OK, so we could add a dwfl_attach_arch_state which is almost like dwfl_attach_state except instead of an ELF it would take machine, class, data. bool dwfl_attach_arch_state (Dwfl *dwfl, GElf_Half e_machine, unsigned char ei_class, unsigned char ei_data, pid_t pid, const Dwfl_Thread_Callbacks *thread_callbacks, void *dwfl_arg); But before we do I like to understand your use case a little better, to make sure it is really necessary (once we add a public interface we are stuck with it forever). First note that providing an Elf handle to dwfl_attach_arch_state isn't necessary if the Dwfl already has Dwfl_Modules, then it can guess the architecture from the Elf associated with the Dwfl_Modules. From the documentation: /* [...] Architecture of DWFL modules is specified by ELF, ELF must remain valid during DWFL lifetime. Use NULL ELF to detect architecture from DWFL, the function will then detect it from arbitrary Dwfl_Module of DWFL. [...] */ So would that be an alternative for you? How do you create the Dwfl? Do you add modules to it (how?) and when do you need to call dwfl_attach_state? Thanks, Mark
Re: dwfl_attach_state alternative taking Ebl?
/* [...] Architecture of DWFL modules is specified by ELF, ELF must remain valid during DWFL lifetime. Use NULL ELF to detect architecture from DWFL, the function will then detect it from arbitrary Dwfl_Module of DWFL. [...] */ So would that be an alternative for you? How do you create the Dwfl? Do you add modules to it (how?) and when do you need to call dwfl_attach_state? This is what we do. We parse perf.data. perf.data may contain information about file mappings at any point, and it may take a while until the first valid one shows up. So we postpone dwfl_attach_state until we have a mapping we can resolve to a local elf file. The code would be cleaner if we could attach_state before starting to parse. And there might be pathological cases where no valid elf file can ever be found but we can still unwind by frame pointer. br, Ulf
