Hi Jeff, Dne 27. 07. 20 v 14:28 Vít Ondruch napsal(a): > Dne 27. 07. 20 v 12:25 Vít Ondruch napsal(a): >> Dne 24. 07. 20 v 21:01 Jeff Law napsal(a): >>> On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote: >>>> The LTO break Ruby on various platforms. >>>> >>>> >>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573 >>>> >>>> vs >>>> >>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733 >>>> >>>> (Note these are my experimental builds testing single test case). >>> I haven't gotten a clean ruby build with or without LTO. >> Ruby builds just fine on x86_64 according to Koschei: >> >> https://koschei.fedoraproject.org/package/ruby? >> >> >>> So I haven't >>> investigated Ruby for any LTO specific failures. >>> >>>> The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33. >>>> Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at >>>> least behaving the same on all platforms :/ >>>> >>>> >>>> And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby? >>>> >>>> Looking at the full test suite, it seems it causes some troubles to >>>> SIGSEV signal handler (Ruby spawns subprocess and kills it). >>> Does the signal handler modify any global variables? >> I am afraid there happens a lot of interesting stuff. This is the method >> responsible for printing the output which likely fails: >> >> https://github.com/ruby/ruby/blame/master/vm_dump.c#L920 >> >> But the issue might be that the signal handler itself might be somehow >> modified and the modification fails. This is the default signal handler: >> >> https://github.com/ruby/ruby/blob/master/signal.c#L1137 >> >> >>> That's been a common source >>> of issues I've seen. >> I am afraid I'll need to open some upstream ticket to help with answers >> to questions like this :/ > > https://bugs.ruby-lang.org/issues/17052 I have upstream response. From the ticket above: ~~~ It seems the generated DWARF section is broken. For instance addr2line(1) also fails to understand it. % nm ./miniruby | fgrep -w rb_f_kill | LC_ALL=C addr2line -e ./miniruby addr2line: Dwarf Error: Could not find abbrev number 64. ??:? :? When you kill LTO option the above one liner must show "signal.c:423" or something. vo.x (Vit Ondruch) is it possible for you to ask this to linker people instead? As addr2line(1) is also affected, it is hard for me to think we are the ones who is doing something wrong. ~~~ HTH Vít > > > Vít > > >> >> Vít >> >> >>> jeff >> _______________________________________________ >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
