Re: elog/ereport VS misleading backtrace_function function address

On 07.05.24 09:43, Jakub Wartak wrote:
> NOTE: in case one will be testing this: one cannot ./configure with
> --enable-debug as it prevents the compiler optimizations that actually
> end up with the ".cold" branch optimizations that cause backtrace() to
> return the wrong address.

Is that configuration useful? If you're interested in backtraces,
wouldn't you also want debug symbols? Don't production builds use debug
symbols nowadays as well?

>> I recall speculating about whether we could somehow invoke gdb
>> to get a more comprehensive and accurate backtrace, but I don't
>> really have a concrete idea how that could be made to work.
> Oh no, I'm more about micro-fix rather than doing some bigger
> revolution. The patch simply adds this one instruction in macro, so
> that now backtrace_functions behaves better:
>
> 0x0000000000773d28 <+105>: call 0x79243f <errfinish>
> 0x0000000000773d2d <+110>: movzbl -0x12(%rbp),%eax << this ends
> up being added by the patch
> 0x0000000000773d31 <+114>: call 0xdc1a0 <abort(at)plt>
>
> I'll put that as for PG18 in CF, but maybe it could be backpatched too
> - no hard opinion on that (I don't see how that ERROR/FATAL path could
> cause any performance regressions)

I'm missing a principled explanation of what this does. I just see that
it sprinkles some no-op code to make this particular thing work a bit
differently, but this might just behave differently with the next
compiler next year. I'd like to see a bit more of an abstract
explanation of what is happening here.