Re: GetPreviousInstructionPc question

On Thu, Apr 20, 2017 at 12:00 PM, Yuri Gribov wrote: > On Thu, Apr 20, 2017 at 10:53 AM, 'Dmitry Vyukov' via > address-sanitizer wrote: >> On Thu, Apr 20, 2017 at 11:50 AM, Yuri Gribov wrote: >>> On Thu, Apr 20, 2017

Re: GetPreviousInstructionPc question

Yuri, I think on ARM we also subtract 1 from pc: #if defined(__arm__) // Cancel Thumb bit. pc = pc & (~1); #endif #if defined(__powerpc__) || defined(__powerpc64__) // ... #elif defined(__sparc__) || defined(__mips__) // ... #else return pc - 1; // Called for ARM as well as for Thumb and

Re: GetPreviousInstructionPc question

On Thu, Apr 20, 2017 at 10:53 AM, 'Dmitry Vyukov' via address-sanitizer wrote: > On Thu, Apr 20, 2017 at 11:50 AM, Yuri Gribov wrote: >> On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via >> address-sanitizer

Re: GetPreviousInstructionPc question

On Thu, Apr 20, 2017 at 11:50 AM, Yuri Gribov wrote: > On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via > address-sanitizer wrote: >> On Thu, Apr 20, 2017 at 11:11 AM, evgeny777 wrote: >>> Thanks for

Re: GetPreviousInstructionPc question

On Thu, Apr 20, 2017 at 11:11 AM, evgeny777 wrote: > Thanks for clarifying it, Dmitry. > > Here is piece of report I get: > > ==18244==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6020001a at pc 0x005a9cad bp 0x7ffc10528760 sp 0x7ffc10528740 >

Re: GetPreviousInstructionPc question

Thanks for clarifying it, Dmitry. Here is piece of report I get: ==18244==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020001a at pc 0x005a9cad bp 0x7ffc10528760 sp 0x7ffc10528740 WRITE of size 1 at 0x6020001a thread T0 #0 0x5a9cac

Re: GetPreviousInstructionPc question

On Thu, Apr 20, 2017 at 10:44 AM, evgeny777 wrote: > I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for both > arm32 and arm64. > This causes odd addresses to appear in stack traces, which is nonsense, as > both arm32/64 instructions > have 4 byte