[Bug 1133245] New: LTO: libsigsegv build fails
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245 Bug ID: 1133245 Summary: LTO: libsigsegv build fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: martin.liska@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Fails due to: [ 45s] /usr/include/asm/sigcontext.h:40:8: error: redefinition of 'struct _fpx_sw_bytes' There's some broken configure: Bad configure: checking whether a fault handler according to Hurd works... no checking ucontext.h usability... yes checking ucontext.h presence... yes checking for ucontext.h... yes vs. checking whether a fault handler according to Hurd works... no checking for the fault handler specifics... fault-linux-x86_64-old.h checking if the system supports catching SIGSEGV... no checking for stack direction... grows down -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
Martin Liška
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c1
Dr. Werner Fink
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c2
--- Comment #2 from Martin Liška
beside this here is the same as with texlive binaries: I do not want to have libsigsegv compiled(linked with lto support!
I accept that: https://build.opensuse.org/request/show/697610 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
Martin Liška
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c4
--- Comment #4 from Dr. Werner Fink
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c5
--- Comment #5 from Martin Liška
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c6
--- Comment #6 from Martin Liška
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c7
--- Comment #7 from Martin Liška
│0x40110e
movl $0x2a,0x678(%rax) │0x401118 cmpl $0x1,0x2f35(%rip) │0x40111f jne 0x401135
So the handler is called before the cmpl instruction.
While with LTO we end up with:
│0x40110b
│0x401112
movl $0x2a,0x678(%rbx) │0x40111c jne 0x401133 │0x40111e add $0xa0,%rsp
So comparison of (handler_called != 1) happens before the store that triggers the handler. It's correct in my opinion to do such transformation. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c8
--- Comment #8 from Dr. Werner Fink
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c9
--- Comment #9 from Dr. Werner Fink
From an old manual page of gcc (Leap 15.0)
Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce unexpected results. now I read on Tumbleweed: Link-time optimization does not work well with generation of debugging information on systems other than those using a combination of ELF and DWARF. may I asked what had beend changeds menawhile? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c10
--- Comment #10 from Martin Liška
Hmm ... the transformation might be correcti(?), but how should libsigsegv catch the first segmentation fault (and only this), if the check is moved in the resulting assembler instructions out of the way? Would the volatile attribute for handler_called help here?
I would recommend to use a memory barrier: asm volatile("" ::: "memory"); More informations: https://stackoverflow.com/questions/14950614/working-of-asm-volatile-memory
Btw: IMHO we need an HOWTO for debugging link time optimized programs within gdb. This because with LTO the core dumps from users/customers become rather useless (IMHO).
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c11
Martin Liška
From an old manual page of gcc (Leap 15.0)
Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce unexpected results.
now I read on Tumbleweed:
Link-time optimization does not work well with generation of debugging information on systems other than those using a combination of ELF and DWARF.
Correct.
may I asked what had beend changeds menawhile?
In GCC 8 we made a significant improvement of the debug info: https://gcc.gnu.org/gcc-8/changes.html Link-time optimization improvements: We have significantly improved debug information on ELF targets using DWARF by properly preserving language-specific information. This allows for example the libstdc++ pretty-printers to work with LTO optimized executables. It's work made by mainly by Richard Biener and it's known as 'Early LTO'. Note that it was a significant effort and program backtraces as well as debugging experience in gdb should be comparable to non-LTO mode. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c12
--- Comment #12 from Dr. Werner Fink
(In reply to Dr. Werner Fink from comment #8)
Hmm ... the transformation might be correcti(?), but how should libsigsegv catch the first segmentation fault (and only this), if the check is moved in the resulting assembler instructions out of the way? Would the volatile attribute for handler_called help here?
I would recommend to use a memory barrier: asm volatile("" ::: "memory");
More informations: https://stackoverflow.com/questions/14950614/working-of-asm-volatile-memory
Btw: IMHO we need an HOWTO for debugging link time optimized programs within gdb. This because with LTO the core dumps from users/customers become rather useless (IMHO).
Ouch .. this is somehow a déjà vu for me as I had in past (15 years back) used memory barriers very often but had been told that this not need anymore with the modern gcc. IMHO it is a bug of the compiler if code is moved in such a way that the logic becomes broken. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c13
--- Comment #13 from Martin Liška
(In reply to Martin Liška from comment #10)
(In reply to Dr. Werner Fink from comment #8)
Hmm ... the transformation might be correcti(?), but how should libsigsegv catch the first segmentation fault (and only this), if the check is moved in the resulting assembler instructions out of the way? Would the volatile attribute for handler_called help here?
I would recommend to use a memory barrier: asm volatile("" ::: "memory");
More informations: https://stackoverflow.com/questions/14950614/working-of-asm-volatile-memory
Btw: IMHO we need an HOWTO for debugging link time optimized programs within gdb. This because with LTO the core dumps from users/customers become rather useless (IMHO).
Ouch .. this is somehow a déjà vu for me as I had in past (15 years back) used memory barriers very often but had been told that this not need anymore with the modern gcc.
IMHO it is a bug of the compiler if code is moved in such a way that the logic becomes broken.
So that I created a GCC issue and let's be given a clarification: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90245 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c14
--- Comment #14 from Dr. Werner Fink
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c15
--- Comment #15 from Martin Liška
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c17
--- Comment #17 from Dr. Werner Fink
Having the configure patch, would you like to enable LTO for the package?
I had tried it and it builds ... but does it work in real life? In my experiences no one can trust a compiler which (re)moves logic from code. In fact in past I had used memory barriers in the body of for loops where the code was only in the boolean and incremental statement to avoid that those loops become removed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c18
--- Comment #18 from Martin Liška
(In reply to Martin Liška from comment #15)
Having the configure patch, would you like to enable LTO for the package?
I had tried it and it builds ... but does it work in real life? In my experiences no one can trust a compiler which (re)moves logic from code.
We name it optimizing compiler :)
In fact in past I had used memory barriers in the body of for loops where the code was only in the boolean and incremental statement to avoid that those loops become removed.
Well you should probably use volatile for the variables which can be influenced by a handlers. Doing that the memory barious should not be needed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c20
--- Comment #20 from Dr. Werner Fink
In fact in past I had used memory barriers in the body of for loops where the code was only in the boolean and incremental statement to avoid that those loops become removed.
Well you should probably use volatile for the variables which can be influenced by a handlers. Doing that the memory barious should not be needed.
In fact using `volatile sig_atomic_t' does also work. Interesting question why
the type sig_atomic_t is not defined with attribute volatile in
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c21
--- Comment #21 from Martin Liška
(In reply to Martin Liška from comment #18)
In fact in past I had used memory barriers in the body of for loops where the code was only in the boolean and incremental statement to avoid that those loops become removed.
Well you should probably use volatile for the variables which can be influenced by a handlers. Doing that the memory barious should not be needed.
In fact using `volatile sig_atomic_t' does also work. Interesting question why the type sig_atomic_t is not defined with attribute volatile in
That's very good question, I asked the same! Can you please send a question to: https://sourceware.org/ml/libc-help/ mailing list? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c22
--- Comment #22 from Dr. Werner Fink
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c23
--- Comment #23 from Martin Liška
RPM lint does not like LTO in static libs
[ 11s] RPMLINT report: [ 11s] =============== [ 12s] libsigsegv-devel.x86_64: W: lto-bytecode /usr/lib64/libsigsegv.a [ 12s] This executable contains a LTO section. LTO bytecode is not portable and [ 12s] should not be distributed in static libraries or e.g. Python modules.
Yep, I've added the check. Using fat LTO objects will handle this: https://en.opensuse.org/openSUSE:LTO#Static_libraries and brp-checks will do LTO bytecode stripping for the static libs. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245
http://bugzilla.opensuse.org/show_bug.cgi?id=1133245#c33
Dr. Werner Fink
participants (1)
-
bugzilla_noreply@novell.com