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@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.