https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #61 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Florian Weimer from comment #58) > (In reply to Dominik Vogt from comment #57) > > libsanitizer miscalculates the Pcs in the backtrace: > > > > #0 0x1000839 in NullDeref > > #1 0x10006c1 in main > > #2 0x3fff6e23069 in __libc_start_main > > #3 0x100073d > > > > These are all odd addresses, pointing to the last byte of the previous > > instruction. In case of null-deref-1.c that byte belongs to some > > instrumentation code that is associated with line 11. > > The address decrement should only happen for call instructions. This thread > has some background how this is supposed to work: > > https://gcc.gnu.org/ml/gcc/2016-10/msg00165.html > https://gcc.gnu.org/ml/gcc/2016-10/msg00170.html ?? We have the "S" .eh_frame augmentation character for that and the reason why _Unwind_GetIPInfo has been added (it tells you whether it is something that is a call or not, and thus whether you need to subtract 1 to get back into the instruction (it doesn't have to be start of the instruction for unwinding purposes) or not. It is true that libasan calls just _Unwind_GetIP rather than _Unwind_GetIPInfo, but I don't see where there is that subtraction of 1, so it shouldn't matter; it seems to record the address that return address that has been given by the unwinder.
