https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #13 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- I see. But what bug or bugs do we have here then? Current symptoms are: (1) A bogus call addres may be stored in the backtrace structure (i.e. next instruction's address minus 1). (2) The address from (1) in printed in the textual backtrace. As I understand it, the code should instead print the address calculated in printStackRecord(). (3) At least for s390[x], the caller's line number in the printed backtrace may be wrong, but I guess that affects other targets as well. -- So, what happens is this: * The code in libbacktrace knows whether the pc points to the call instruction or the instruction after that and handles the latter by decrementing the pc by one before it's stored in some structure describing the stack trace. * When the user prints a memory heap trace, writeHeap() is called, which prints the address from the stack trace structure and then calls printStackRecord(). * printStackRecord() then deducts the guessed size of the call instruction from the pc and uses this modified pc to determine the file and line number to print in the stack trace. -- I see at least two things that need to be fixed: - printStackRecord() needs to know whether the pc has already been decremented in libbacktrace and adapt the calculation accordingly. On s390[x] this could simply be done by looking at the pc, because odd pcs are invalid. This is not the case on other architectures though (e.g. ARM7). - writeHeap should print the address calculated in printStackRecord() instead of the address from the stack trace structure. As an alternative, if the code in libbacktrace could properly determine the call address, the address calculation code in printStackTrace() could be removed and everything would be fine.
