lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] ICE with '-fno-omit-frame-pointer', 64-bit msw [Was: Segfault


From: Greg Chicares
Subject: Re: [lmi] ICE with '-fno-omit-frame-pointer', 64-bit msw [Was: Segfault in wxGrid]
Date: Thu, 10 Dec 2020 13:26:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 3/23/19 4:35 PM, Vadim Zeitlin wrote:
> On Sat, 23 Mar 2019 16:15:36 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> We've been using '-fno-omit-frame-pointer' since 2016. However, we
> GC> may have to inhibit it for x86_64-w64-mingw32-gcc version 8.2.0
> GC> due to a compiler defect:
> 
>  This is unfortunate, but IME we don't use stack traces generated by
> production binaries much anyhow, so it's probably not that important.

It is, however, recommended to use '-fno-omit-frame-pointer' with 'perf':

http://www.brendangregg.com/blog/2014-06-22/perf-cpu-sample.html

| Incomplete stacks usually mean -fomit-frame-pointer was used – a compiler
| optimization that makes little positive difference in the real world, but
| breaks stack profilers. Always compile with -fno-omit-frame-pointer. More
| recent perf has a -g dwarf option, to use the alternate libunwind/dwarf
| method for retrieving stacks.

Even though "alternate" methods are available, '-fomit-frame-pointer'
is a dubious optimization. It made some sense to treat BP as a general-
purpose register on 1980s hardware, but the x86_64 architecture has a
more bountiful supply of registers. In particular, measurements
show that '-fomit-frame-pointer' has no benefit at all for lmi:
  https://lists.nongnu.org/archive/html/lmi/2016-07/msg00008.html
and did actually make debugging more difficult:
  https://lists.nongnu.org/archive/html/lmi/2016-06/msg00090.html
Furthermore, the "alternate" methods appear to involve emulating in
software what the CPU already does faster and more reliably.

> GC> This gcc-8.1 defect report:
> GC>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593
> GC> seems to be relevant, although the diagnostic I see refers to a
> GC> different line in 'based_loc_descr'.
> 
>  But it also looks to be triggered by very similar code, so it seems to be
> almost certain to be the same bug. Perhaps it will be backported to 8.x
> branch by the time of the next release, but in any case it will certainly
> be fixed in gcc 9 which shouldn't be too far away.

I haven't tried gcc-9 (which we don't plan to use in production
anyway), but with gcc-10 it does seem to be fixed--the testcase
from my original post, updated thus:

x86_64-w64-mingw32-g++ -c -DBOOST_NO_AUTO_PTR -I /opt/lmi/src/lmi -I 
/opt/lmi/third_party/include -I /opt/lmi/local/include -I 
/opt/lmi/x86_64-w64-mingw32/local/include -std=c++17 -Werror -ggdb -O2 
-fno-omit-frame-pointer /opt/lmi/src/lmi/accountvalue.cpp -oaccountvalue.o 2>&1 
|less -S

succeeds with gcc-10, but fails with gcc-8. Accordingly, I'll
restrict the '-fomit-frame-pointer' workaround to
x86_64-w64-mingw32-gcc-8.x only, so that it doesn't propagate
to gcc-10 builds when we upgrade the compiler (very soon).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]