Removed the 'bkpt' instruction in file 'base/logging.h' from line:
   asm volatile("bkpt #0; udf %0;" ::"i"(__COUNTER__ % 256))
and Breakpad started reading /proc/pid/auxv without problems.

Thanks for the report, a bunch of things are not clear to me:

1. It seems that we always try to read "auxv", as that is in 
bool LinuxDumper::Init() {
 return ReadAuxv() & ... other stuff
}
so not clear how is the change in logging.h making that any different.

2. Looks like the fact that we cannot read auxv is sort of known.
Somewhere else in minidump_writer.cc I see:
    // Parse /proc/cpuinfo to reconstruct the CPUID value, as well
    // as the ELF hwcaps field. For the latter, it would be easier to
    // read /proc/self/auxv but unfortunately, this file is not always
    // readable from regular Android applications on later versions
    // (>= 4.1) of the Android platform.

So the problem here is actually the fact that reading auxv shouldn't be fatal.

I am quite against changing logging.h because that has very complex implication on the crash reports and every time we touched something in those macros, something else broke along the way.
It seems that the thing that needs to be fixed is not relying on the ability of reading auxv.

> Removed the 'bkpt' instruction in file 'base/logging.h' from line:
>   asm volatile("bkpt #0; udf %0;" ::"i"(__COUNTER__ % 256))
> and Breakpad started reading /proc/pid/auxv without problems.

Ah, so looks like our ability to read auxv depeds on which specific instruction we ran before crashing?
That sounds a kernel bug to me. But even if that's the case we should fix this in breakpad not in chrome's base.

+mark/rsesek/torne