https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87071
--- Comment #7 from Sergey Kondakov <virtuousfox at gmail dot com> --- Created attachment 44583 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44583&action=edit Xorg.pid-1381.gdb.log with disas (In reply to Alexander Monakov from comment #6) > In your gdb script, please add > > x/i $pc > disas > > after the backtrace command (probably 'bt full') and regenerate the log. > Without that the log doesn't actually show the "illegal" instruction. > Now, THAT's some real advice, thanks ! I've managed get that log but… > Also please show output of rpm -qf /usr/lib64/dri/r300_dri.so This, of course, points to Mesa-dri package BUT that gave me an idea to not rule out Mesa yet. And, indeed, it was the culprit all along, despite of what its dev have said. Or, more accurately, it was clang/LLVM… probably, I haven't properly checked yet. I've forked distro package (or, more precisely, its auto-build OBS scripts) of Mesa to build it with LTO and decrease its monstrous size. But it doesn't compile with gcc that way because of a long-standing bug and broken autotools scripts + OBS can't handle requirements of full LTO anyway. So I used clang & gold for building Mesa (and only it) with ThinLTO and it worked (and works, on newer PCs) fine. I spent days on figuring that out and hours on fighting package manager to selectively install "old", default Mesa package-set without affecting anything else. And it worked, crash is gone. Maybe it was combination of factors but I shouldn't have believed Mesa is irrelevant, as I was told, just because it's far from being the first in the chain of jumps of the backtrace. But then again, I don't have much clue about how it works. So, this issue can be closed UNLESS you think that backtrace shouldn't have lead to libstdc++ anyway and/or clang & Mesa couldn't have failed like that on their own. Normally, such suicidal code should not come out of a compiler with almost-default non-aggressive settings, wherever it may be. (In reply to Uroš Bizjak from comment #4) > (In reply to Sergey Kondakov from comment #3) > > > If your code is correct then whose isn't ? > Instructions are generated by the compiler. So, it is the compiler's fault, > it probably emits a SSE instruction that your processor doesn't understand. > > That said, at least we need a runtime testcase that fails on your target. If > this is not possible, then please at least decompile the library and show > the instruction that fails. We also need preprocessed source and exact > instructions, how to build the source, so the illegal insn will be generated. > > Also, please read https://gcc.gnu.org/bugs/ Oh, I've read that, all right. Full verbose (very, very verbose) build logs, self-tests, compilation scripts and built gcc/libstdc++ packages are in the OBS links in the original post, more precisely: https://build.opensuse.org/package/live_build_log/devel:gcc/gcc8/openSUSE_Factory/x86_64 https://build.opensuse.org/package/binaries/devel:gcc/gcc8/openSUSE_Factory (requires OBS registration to show download links) https://download.opensuse.org/repositories/devel:/gcc/openSUSE_Factory/ (does not require registration but page with massive package-listing halts browser and requires a lot of RAM to view) Except for https://build.opensuse.org/package/show/home:X0F:HSF/Mesa where my Mesa-dri:r300_dri.so is built. But asking to decompile one of the core system libraries or make an example, faulty program on a spot is like asking to decompile kernel or write a driver (actually, probably even worse): anyone capable of doing it in a day does not require anyone else's software-related assistance. (In reply to Jonathan Wakely from comment #5) > Right. As you can see in GDB, the libstdc++ code says: > > 350 return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, > __n)); > > Do you see any processor instructions there? Anything that isn't valid on > your CPU? No, because it's just C++ code. I see a bunch of over-complicated gibberish starting with libstdc++ which was used as an argument by widely-known, reputable and respected Mesa developer to look into libstdc++. Your reclussive, insular existance and passive-aggressive "deal with issues of our _irreplaceable_ software, requiring high-level low-abstraction-layer engineer-grade knowledge and experience, yourself"-attitude in relation to one of the most obscure subject matters, on the other hand, begets only distrust and frustration. As the result, I spent almost no time investigating my suspicion which was correct in the first place, spent a lot of effort to investigate his claim and couldn't do anything with yours because of how non-productive it was. > (In reply to Uroš Bizjak from comment #4) > > Also, please read https://gcc.gnu.org/bugs/ > > I already said that before the bug was even filed. No wonder googling "gcc bugzilla registration" brings up an upvoted years-old post that's advising not to bother.
