Re: Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)
On Tue, Aug 04, 2020 at 11:24:24AM +0200, Mark Wielaard wrote: > Hi Richard, > > On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote: > > In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log > > (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877) > > I'm still seeing errors like: > > > > /usr/lib/rpm/debugedit: > > /builddir/build/BUILDROOT/ocaml-ppx-tools-versioned-5.4.0-5.fc33.x86_64/usr/lib64/ocaml/ppx_tools_versioned/metaquot_409/ppx.exe: > > DWARF version 0 unhandled > > > > This is with binutils 2.35-10.fc33 which AFAIK should fix this. > > [...] > > + gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall > > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS > > -fexceptions -fstack-protector-strong -grecord-gcc-switches > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall > > -Wdeclaration-after-statement -Werror -fno-common > > -fexcess-precision=standard -fno-tree-vrp -ffunction-sections > > -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE -Wl,-E -o > > '.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe' > > '-L/usr/lib64/ocaml/compiler-libs' > > '-L/usr/lib64/ocaml/ocaml-migrate-parsetree' > > '-L/usr/lib64/ocaml/ppx_derivers' '-L/usr/lib64/ocaml/result' '-L.' > > '-L.ppx_tools_versioned.objs/byte' '-L.ppx_tools_versioned.objs/native' > > '-L.ppx_tools_versioned_metaquot_409.objs/byte' > > '-L.ppx_tools_versioned_metaquot_409.objs/native' '-L/usr/lib64/ocaml' > > '/tmp/camlstartup93ae0f.o' '/usr/lib64/ocaml/std_exit.o' > > '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' > > 'ppx_tools_versioned_metaquot_409.a' 'ppx_tools_versioned.a' > > '/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.a' > > '/usr/lib64/ocaml/ppx_derivers/ppx_derivers.a' > > '/usr/lib64/ocaml/result/result.a' > > '/usr/lib64/ocaml/compiler-libs/ocamlcommon.a' '/usr/lib64/ocaml/stdlib.a' > > '/usr/lib64/ocaml/libasmrun.a' -Wl,-z,relro -Wl,--as-needed -Wl,-z,now > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl > > > > Not sure how to diagnose this further. None of this is reproducible > > for me locally even with all the same Rawhide packages installed. > > If I had to guess, then I would guess that one of the static libraries > under /usr/lib/64/ocaml/*.a contain bad DWARF. Might it be that one of > those was build with a bad binutils gas? That's a good point. I realised that locally I had a slightly older OCaml package than what is in Rawhide. Upgrading to ocaml-4.11.0-0.7.dev2.fc33 and trying to build ocaml-ppx-tools-versioned and *yes* I'm able to reproduce the problem locally. This would indicate a problem in *.a files in the OCaml package as you say. I'll rebuild it (the OCaml package) and see if I can fix the problem in Koji that way. Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)
Hi Richard, On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote: > In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log > (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877) > I'm still seeing errors like: > > /usr/lib/rpm/debugedit: > /builddir/build/BUILDROOT/ocaml-ppx-tools-versioned-5.4.0-5.fc33.x86_64/usr/lib64/ocaml/ppx_tools_versioned/metaquot_409/ppx.exe: > DWARF version 0 unhandled > > This is with binutils 2.35-10.fc33 which AFAIK should fix this. > [...] > + gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS > -fexceptions -fstack-protector-strong -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall > -Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard > -fno-tree-vrp -ffunction-sections -D_FILE_OFFSET_BITS=64 -D_REENTRANT > -DCAML_NAME_SPACE -Wl,-E -o '.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe' > '-L/usr/lib64/ocaml/compiler-libs' > '-L/usr/lib64/ocaml/ocaml-migrate-parsetree' > '-L/usr/lib64/ocaml/ppx_derivers' '-L/usr/lib64/ocaml/result' '-L.' > '-L.ppx_tools_versioned.objs/byte' '-L.ppx_tools_versioned.objs/native' > '-L.ppx_tools_versioned_metaquot_409.objs/byte' > '-L.ppx_tools_versioned_metaquot_409.objs/native' '-L/usr/lib64/ocaml' > '/tmp/camlstartup93ae0f.o' '/usr/lib64/ocaml/std_exit.o' > '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' > 'ppx_tools_versioned_metaquot_409.a' 'ppx_tools_versioned.a' > '/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.a' > '/usr/lib64/ocaml/ppx_derivers/ppx_derivers.a' > '/usr/lib64/ocaml/result/result.a' > '/usr/lib64/ocaml/compiler-libs/ocamlcommon.a' '/usr/lib64/ocaml/stdlib.a' > '/usr/lib64/ocaml/libasmrun.a' -Wl,-z,relro -Wl,--as-needed -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl > > Not sure how to diagnose this further. None of this is reproducible > for me locally even with all the same Rawhide packages installed. If I had to guess, then I would guess that one of the static libraries under /usr/lib/64/ocaml/*.a contain bad DWARF. Might it be that one of those was build with a bad binutils gas? Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)
In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877) I'm still seeing errors like: /usr/lib/rpm/debugedit: /builddir/build/BUILDROOT/ocaml-ppx-tools-versioned-5.4.0-5.fc33.x86_64/usr/lib64/ocaml/ppx_tools_versioned/metaquot_409/ppx.exe: DWARF version 0 unhandled This is with binutils 2.35-10.fc33 which AFAIK should fix this. The ocamlopt command which generates this file is: Running[230]: (cd _build/default && /usr/bin/ocamlopt.opt -g -o .ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe -w -24 -I /usr/lib64/ocaml/compiler-libs -I /usr/lib64/ocaml/ocaml-migrate-parsetree -I /usr/lib64/ocaml/ppx_derivers -I /usr/lib64/ocaml/result -I . -I .ppx_tools_versioned.objs/byte -I .ppx_tools_versioned.objs/native -I .ppx_tools_versioned_metaquot_409.objs/byte -I .ppx_tools_versioned_metaquot_409.objs/native /usr/lib64/ocaml/compiler-libs/ocamlcommon.cmxa /usr/lib64/ocaml/result/result.cmxa /usr/lib64/ocaml/ppx_derivers/ppx_derivers.cmxa /usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.cmxa ppx_tools_versioned.cmxa ppx_tools_versioned_metaquot_409.cmxa .ppx/344604af5ef56e11f45ae295381bcce7/_ppx.ml) which runs: + as -o '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' '/tmp/camlasmca413d.s' + as -o '/tmp/camlstartup93ae0f.o' '/tmp/camlstartup1ccce5.s' + gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall -Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard -fno-tree-vrp -ffunction-sections -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE -Wl,-E -o '.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe' '-L/usr/lib64/ocaml/compiler-libs' '-L/usr/lib64/ocaml/ocaml-migrate-parsetree' '-L/usr/lib64/ocaml/ppx_derivers' '-L/usr/lib64/ocaml/result' '-L.' '-L.ppx_tools_versioned.objs/byte' '-L.ppx_tools_versioned.objs/native' '-L.ppx_tools_versioned_metaquot_409.objs/byte' '-L.ppx_tools_versioned_metaquot_409.objs/native' '-L/usr/lib64/ocaml' '/tmp/camlstartup93ae0f.o' '/usr/lib64/ocaml/std_exit.o' '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' 'ppx_tools_versioned_metaquot_409.a' 'ppx_tools_versioned.a' '/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.a' '/usr/lib64/ocaml/ppx_derivers/ppx_derivers.a' '/usr/lib64/ocaml/result/result.a' '/usr/lib64/ocaml/compiler-libs/ocamlcommon.a' '/usr/lib64/ocaml/stdlib.a' '/usr/lib64/ocaml/libasmrun.a' -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl Not sure how to diagnose this further. None of this is reproducible for me locally even with all the same Rawhide packages installed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Richard, > guestfish on x86-64 was failing for me with something that looks a lot > like the same PLT problem. But it's not aarch64. Very easy to > reproduce, see: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/ This looks like it might be the binutils/LTO thing: https://sourceware.org/bugzilla/show_bug.cgi?id=26314 The patches for that PR are now in rawhide and a rebuild is taking place, (It has not finished yet as builds are taking a very long time today). Look for binutils-2.35-8.fc33 to appear in the buildroot and then try again. Cheers Nick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Fri, 2020-07-31 at 12:44 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote: > > That binutils was rebuilt (thanks to Richard Jones) and I have now > > built an even newer one which contains a fix for AArch64 PLT problems. > > Both of these are built with LTO disabled, so the bug should not affect > > them. > > guestfish on x86-64 was failing for me with something that looks a lot > like the same PLT problem. But it's not aarch64. Very easy to > reproduce, see: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/ Just for the record, I don't think that is the aarch64 plt thing. Which is https://bugzilla.redhat.com/show_bug.cgi?id=1862110 That would show up as "Failed to update file: invalid section entry size". I think this is a real LTO issue (both the aarch64 plt and zero DWARF version weren't, just "normal" bugs in binutils as and binutils ld, unrelated to LTO). Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote: > Hi Guys, > > >> Yes, because the commit adding the DWARF 4 patch has also > >> turned LTO back on... > > *double sigh*. Yes I was trying to fix the LTO bug at the same time, > and forgot that I had re-enabled it in my local copy of the rawhide > sources in order to investigate the problems. > > That binutils was rebuilt (thanks to Richard Jones) and I have now > built an even newer one which contains a fix for AArch64 PLT problems. > Both of these are built with LTO disabled, so the bug should not affect them. guestfish on x86-64 was failing for me with something that looks a lot like the same PLT problem. But it's not aarch64. Very easy to reproduce, see: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Guys, >> Yes, because the commit adding the DWARF 4 patch has also >> turned LTO back on... *double sigh*. Yes I was trying to fix the LTO bug at the same time, and forgot that I had re-enabled it in my local copy of the rawhide sources in order to investigate the problems. That binutils was rebuilt (thanks to Richard Jones) and I have now built an even newer one which contains a fix for AArch64 PLT problems. Both of these are built with LTO disabled, so the bug should not affect them. Cheers Nick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Thu, Jul 30, 2020 at 10:37:22PM +0100, Richard W.M. Jones wrote: > On Thu, Jul 30, 2020 at 10:33:18PM +0100, Richard W.M. Jones wrote: > > On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote: > > > On 30/07/2020 22:18, Richard W.M. Jones wrote: > > > > > > >That problem is fixed, but binutils "ar" utility in Rawhide > > > >again segfaults, eg: > > > > > > Yes, because the commit adding the DWARF 4 patch has also > > > turned LTO back on... > > > > Since this is causing a lot of trouble I have kicked off a binutils > > build with the DWARF fix and with LTO turned off again: > > > > https://src.fedoraproject.org/rpms/binutils/c/6442193bfff72a2b538bf2cb32110850033dea24?branch=master > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48214888 > > Of course that failed because one of the first things it tries to do > is run "ar", which comes from the broken binutils and fails. > > We need someone to untag the broken binutils-2.35-5.fc33 and then > issue a new binutils build. (I cannot do this) We got the bad build untagged, and this is the new build: https://koji.fedoraproject.org/koji/taskinfo?taskID=48216175 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Thu, Jul 30, 2020 at 10:33:18PM +0100, Richard W.M. Jones wrote: > On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote: > > On 30/07/2020 22:18, Richard W.M. Jones wrote: > > > > >That problem is fixed, but binutils "ar" utility in Rawhide > > >again segfaults, eg: > > > > Yes, because the commit adding the DWARF 4 patch has also > > turned LTO back on... > > Since this is causing a lot of trouble I have kicked off a binutils > build with the DWARF fix and with LTO turned off again: > > https://src.fedoraproject.org/rpms/binutils/c/6442193bfff72a2b538bf2cb32110850033dea24?branch=master > https://koji.fedoraproject.org/koji/taskinfo?taskID=48214888 Of course that failed because one of the first things it tries to do is run "ar", which comes from the broken binutils and fails. We need someone to untag the broken binutils-2.35-5.fc33 and then issue a new binutils build. (I cannot do this) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote: > On 30/07/2020 22:18, Richard W.M. Jones wrote: > > >That problem is fixed, but binutils "ar" utility in Rawhide > >again segfaults, eg: > > Yes, because the commit adding the DWARF 4 patch has also > turned LTO back on... Since this is causing a lot of trouble I have kicked off a binutils build with the DWARF fix and with LTO turned off again: https://src.fedoraproject.org/rpms/binutils/c/6442193bfff72a2b538bf2cb32110850033dea24?branch=master https://koji.fedoraproject.org/koji/taskinfo?taskID=48214888 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On 30/07/2020 22:26, Tom Hughes via devel wrote: On 30/07/2020 22:18, Richard W.M. Jones wrote: That problem is fixed, but binutils "ar" utility in Rawhide again segfaults, eg: Yes, because the commit adding the DWARF 4 patch has also turned LTO back on... ...and for extra fun the broken build is on f33-rebuild by the looks of it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On 30/07/2020 22:18, Richard W.M. Jones wrote: That problem is fixed, but binutils "ar" utility in Rawhide again segfaults, eg: Yes, because the commit adding the DWARF 4 patch has also turned LTO back on... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Thu, Jul 30, 2020 at 10:18:18PM +0100, Richard W.M. Jones wrote: > > That problem is fixed, but binutils "ar" utility in Rawhide > again segfaults, eg: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48212210 > https://kojipkgs.fedoraproject.org//work/tasks/2210/48212210/build.log > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48213712 > https://kojipkgs.fedoraproject.org//work/tasks/3712/48213712/build.log Another report of the same thing: https://kojipkgs.fedoraproject.org//work/tasks/3530/48213530/build.log Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
That problem is fixed, but binutils "ar" utility in Rawhide again segfaults, eg: https://koji.fedoraproject.org/koji/taskinfo?taskID=48212210 https://kojipkgs.fedoraproject.org//work/tasks/2210/48212210/build.log https://koji.fedoraproject.org/koji/taskinfo?taskID=48213712 https://kojipkgs.fedoraproject.org//work/tasks/3712/48213712/build.log Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Thanks Nick, the binutils change does appear to have solved the problem: https://koji.fedoraproject.org/koji/taskinfo?taskID=48212537 https://kojipkgs.fedoraproject.org//work/tasks/2537/48212537/build.log Note (for Xavier) that I did NOT need to make any change to OCaml or the flags that it passes to gas. I think we can say this problem is fixed at the moment. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Guys, > Looks like most are simply because the default DWARF version changed to > 4 and the test expected another version even though it didn't specify > one. Yes - it was a silly snafu. I set the default to 4 but the tests are expecting 3. I have now updated the patch and a new binutils (2.23-5.fc33) is building... Cheers Nick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Guys, > Looks like most are simply because the default DWARF version changed to > 4 and the test expected another version even though it didn't specify > one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Richard, On Thu, 2020-07-30 at 12:01 +0100, Richard W.M. Jones wrote: > On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote: > > I will apply this patch to the rawhide binutils (and the upstream > > binutils sources). > > I don't know how worried we should be about this, but it seems every > test in the x86-64 build failed (although the build was successful): > > https://kojipkgs.fedoraproject.org//work/tasks/6878/48186878/build.log Nick is on it: https://sourceware.org/pipermail/binutils/2020-July/112637.html Looks like most are simply because the default DWARF version changed to 4 and the test expected another version even though it didn't specify one. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote: > I will apply this patch to the rawhide binutils (and the upstream binutils > sources). I don't know how worried we should be about this, but it seems every test in the x86-64 build failed (although the build was successful): https://kojipkgs.fedoraproject.org//work/tasks/6878/48186878/build.log Whereas if we look at the corresponding x86-64 log from the previous build the tests didn't fail: https://kojipkgs.fedoraproject.org//packages/binutils/2.35/3.fc33/data/logs/x86_64/build.log Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote: > Hi Guys, > > > But... in 2.35 you can give the DWARF level you want. > > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > > dwarf_level is never set! And then gas will happily create an > > .debug_info section with DWARF CUs that have a version of zero (!). > > Doh! > > > This, defaulting to version 4. Fixes it for me: > > > > diff --git a/gas/as.c b/gas/as.c > > index 4c5881abd88..c2da78870ef 100644 > > --- a/gas/as.c > > +++ b/gas/as.c > > @@ -103,7 +103,7 @@ int verbose = 0; > > int flag_dwarf_cie_version = -1; > > > > /* The maximum level of DWARF DEBUG information we should manufacture. */ > > -unsigned int dwarf_level = 0; > > +unsigned int dwarf_level = 4; > > > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; > > I will apply this patch to the rawhide binutils (and the upstream binutils > sources). Thanks Nick - I will test this as soon as I see the binutils package in Rawhide. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Guys, > But... in 2.35 you can give the DWARF level you want. > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > dwarf_level is never set! And then gas will happily create an > .debug_info section with DWARF CUs that have a version of zero (!). Doh! > This, defaulting to version 4. Fixes it for me: > > diff --git a/gas/as.c b/gas/as.c > index 4c5881abd88..c2da78870ef 100644 > --- a/gas/as.c > +++ b/gas/as.c > @@ -103,7 +103,7 @@ int verbose = 0; > int flag_dwarf_cie_version = -1; > > /* The maximum level of DWARF DEBUG information we should manufacture. */ > -unsigned int dwarf_level = 0; > +unsigned int dwarf_level = 4; > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; I will apply this patch to the rawhide binutils (and the upstream binutils sources). Thanks for finding the problem Mark. Cheers Nick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Jakub, On Wed, 2020-07-29 at 19:10 +0200, Jakub Jelinek wrote: > On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > > Yes, I think we have a winner! > > gas generates a tiny bit of debuginfo even if you don't supply -g. > > > > But... in 2.35 you can give the DWARF level you want. > > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > > dwarf_level is never set! And then gas will happily create an > > .debug_info section with DWARF CUs that have a version of zero (!). > > > > This, defaulting to version 4. Fixes it for me: > > Older as versions emitted DWARF 2, so wouldn't that be a better default > and let gcc pass --gdwarf-? to as if it detects support at compile time > depending on gcc's default dwarf version or -gdwarf-N option? Defaulting to dwarf_level = 2 in the patch should also work. But I think it is high time we defaulted all tools to DWARF version 4 these days. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Richard, On Wed, 2020-07-29 at 17:55 +0100, Richard W.M. Jones wrote: > On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > > This, defaulting to version 4. Fixes it for me: > > > > diff --git a/gas/as.c b/gas/as.c > > index 4c5881abd88..c2da78870ef 100644 > > --- a/gas/as.c > > +++ b/gas/as.c > > @@ -103,7 +103,7 @@ int verbose = 0; > > int flag_dwarf_cie_version = -1; > > > > /* The maximum level of DWARF DEBUG information we should manufacture. */ > > -unsigned int dwarf_level = 0; > > +unsigned int dwarf_level = 4; > > > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; > > So if I understand the proposed fix correctly, we _don't_ need to pass > the -g option to gas? Or should we do that also? Currently passing -g to gas is a workaround. But IMHO it shouldn't be necessary. It isn't necessary with the patch above. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Xavier, On Wed, 2020-07-29 at 18:50 +0200, Xavier Leroy wrote: > If we need to add a directive to the generated assembly, or pass a `-g` > option to the assembler, or use `gcc -c -g` as the assembler, let us know > and we'll see what we can do. > > However, please keep backward compatibility in mind: from the Info manual > it looks like gas version 2.34 has no `-g` option and no directives to > control the generation of DWARF information. So there should be reasonable > defaults for gas 2.35 to behave roughly like gas 2.34. I think the change in binutils/gas 2.35 was supposed to be backward compatible. I am pretty sure it was just an oversight that the DWARF version (dwarf_level) was not set in the none -g case. Lets see what Nick (the binutils maintainer) says. My patch is just the first thing I came up with. I am sure there are other ways to fix this. Cheers, Mark > > But... in 2.35 you can give the DWARF level you want. > > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > > dwarf_level is never set! And then gas will happily create an > > .debug_info section with DWARF CUs that have a version of zero (!). > > > > This, defaulting to version 4. Fixes it for me: > > > > diff --git a/gas/as.c b/gas/as.c > > index 4c5881abd88..c2da78870ef 100644 > > --- a/gas/as.c > > +++ b/gas/as.c > > @@ -103,7 +103,7 @@ int verbose = 0; > > int flag_dwarf_cie_version = -1; > > > > /* The maximum level of DWARF DEBUG information we should > > manufacture. */ > > -unsigned int dwarf_level = 0; > > +unsigned int dwarf_level = 4; > > > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > Yes, I think we have a winner! > gas generates a tiny bit of debuginfo even if you don't supply -g. > > But... in 2.35 you can give the DWARF level you want. > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > dwarf_level is never set! And then gas will happily create an > .debug_info section with DWARF CUs that have a version of zero (!). > > This, defaulting to version 4. Fixes it for me: Older as versions emitted DWARF 2, so wouldn't that be a better default and let gcc pass --gdwarf-? to as if it detects support at compile time depending on gcc's default dwarf version or -gdwarf-N option? Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 10:56 AM Jerry James wrote: > No, it is just called like this: as -o hacha.o hacha.s. Anyway, "info > ld" claims that the -g flag is ignored. No, that was the old "info ld" that said that. The -g flag isn't even mentioned in the new binutils info page. But it is necessary. If I add -g to the "as" invocation, then dwarfdump is suddenly happy. Richard, it looks like we have to make sure the ocaml toolchain passes -g to as now. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 06:50:43PM +0200, Xavier Leroy wrote: > However, please keep backward compatibility in mind: from the Info manual > it looks like gas version 2.34 has no `-g` option and no directives to > control the generation of DWARF information. So there should be reasonable > defaults for gas 2.35 to behave roughly like gas 2.34. It might be that the info file is out of date (my copy of the info file doesn't even mention "as"!), but gas even back to 2.27 has the -g option: $ as --version GNU assembler version 2.27-43.base.el7 Copyright (C) 2016 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-redhat-linux'. $ echo 'nothing: ret' | as -g $ file a.out a.out: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped $ eu-readelf --debug-dump a.out DWARF section [ 6] '.debug_info' at offset 0x83: [Offset] [...lots of stuff...] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 10:51 AM Mark Wielaard wrote:
> I also tried to do a mockbuild locally, and that one succeeded.
> Don't know what is different from the koji buildroot :{
Run mock with --enablerepo=local.
> So ml depends on binutils gas to generate the actual debuginfo.
> I assume it gets called with: as -g
No, it is just called like this: as -o hacha.o hacha.s. Anyway, "info
ld" claims that the -g flag is ignored.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote: > > (Adding OCaml author) > > (Adding binutils/gas maintainer) > > > On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote: > > > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote: > > I should probably add that I'm building these on my local machine > > which isn't completely updated to Rawhide. I'm not sure whether or > > not that will make a difference - I'm assuming _not_ for what the > > OCaml compiler generates (since I'm running the latest of that), but > > not sure about the rest of the toolchain. I'm using > > binutils-2.34-3.fc32.x86_64. > > Right. Same here. Dunno why mockbuild didn't pick up the 2.35 version, > but I think the bug is in that one. See below. > > > > > I also saved an asm file from one of them which may be helpful: > > > > > > > > http://oirase.annexia.org/tmp/hacha.s > > > > > > So ml depends on binutils gas to generate the actual debuginfo. > > > I assume it gets called with: as -g > > > Is there a way to see how exactly gas is called (with which arguments)? > > > > In fact it *isn't* passing -g to as: > > > > $ /usr/bin/ocamlopt.opt -c -w +a-3-4-9-41-45-67 -g -annot -safe-string -o > > hacha.cmx hacha.ml -S -verbose > > + as -o 'hacha.o' 'hacha.s' > > > > Is this a problem? I sort of assumed that as would have nothing to do > > with generating debug information, beyond what is contained explicitly > > in the .s file itself. > > Yes, I think we have a winner! > gas generates a tiny bit of debuginfo even if you don't supply -g. > > But... in 2.35 you can give the DWARF level you want. > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the > dwarf_level is never set! And then gas will happily create an > .debug_info section with DWARF CUs that have a version of zero (!). > > This, defaulting to version 4. Fixes it for me: > > diff --git a/gas/as.c b/gas/as.c > index 4c5881abd88..c2da78870ef 100644 > --- a/gas/as.c > +++ b/gas/as.c > @@ -103,7 +103,7 @@ int verbose = 0; > int flag_dwarf_cie_version = -1; > > /* The maximum level of DWARF DEBUG information we should manufacture. */ > -unsigned int dwarf_level = 0; > +unsigned int dwarf_level = 4; > > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; So if I understand the proposed fix correctly, we _don't_ need to pass the -g option to gas? Or should we do that also? I see that binutils gas back to at least 2.27 has a -g option Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
I got so focused on the other thread, I didn't pay attention to this one. On Wed, Jul 29, 2020 at 10:02 AM Richard W.M. Jones wrote: > It uses its own DWARF generator but everything is linked together > using standard binutils (via GCC). > > > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we > > can inspect it? > > I've uploaded the binary which I built on my own machine here: > > http://oirase.annexia.org/tmp/hacha.native > > plus some of the *.o files which went into it: > > http://oirase.annexia.org/tmp/myLexing.o > http://oirase.annexia.org/tmp/myStack.o > http://oirase.annexia.org/tmp/hacha.o > > I also saved an asm file from one of them which may be helpful: > > http://oirase.annexia.org/tmp/hacha.s As I noted in the other thread, simply running such a .s file through the as from binutils-2.35-3.fc33 then inspecting the output with dwarfdump shows the debuginfo is corrupted. Running the same .s file through the as from binutils-2.34.0-8.fc33, on the other hand, keeps dwarfdump happy. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi, On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote: > (Adding OCaml author) (Adding binutils/gas maintainer) > On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote: > > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote: > I should probably add that I'm building these on my local machine > which isn't completely updated to Rawhide. I'm not sure whether or > not that will make a difference - I'm assuming _not_ for what the > OCaml compiler generates (since I'm running the latest of that), but > not sure about the rest of the toolchain. I'm using > binutils-2.34-3.fc32.x86_64. Right. Same here. Dunno why mockbuild didn't pick up the 2.35 version, but I think the bug is in that one. See below. > > > I also saved an asm file from one of them which may be helpful: > > > > > > http://oirase.annexia.org/tmp/hacha.s > > > > So ml depends on binutils gas to generate the actual debuginfo. > > I assume it gets called with: as -g > > Is there a way to see how exactly gas is called (with which arguments)? > > In fact it *isn't* passing -g to as: > > $ /usr/bin/ocamlopt.opt -c -w +a-3-4-9-41-45-67 -g -annot -safe-string -o > hacha.cmx hacha.ml -S -verbose > + as -o 'hacha.o' 'hacha.s' > > Is this a problem? I sort of assumed that as would have nothing to do > with generating debug information, beyond what is contained explicitly > in the .s file itself. Yes, I think we have a winner! gas generates a tiny bit of debuginfo even if you don't supply -g. But... in 2.35 you can give the DWARF level you want. The problem with not supplying -g (or --gdwarf-[VERSION]) is that the dwarf_level is never set! And then gas will happily create an .debug_info section with DWARF CUs that have a version of zero (!). This, defaulting to version 4. Fixes it for me: diff --git a/gas/as.c b/gas/as.c index 4c5881abd88..c2da78870ef 100644 --- a/gas/as.c +++ b/gas/as.c @@ -103,7 +103,7 @@ int verbose = 0; int flag_dwarf_cie_version = -1; /* The maximum level of DWARF DEBUG information we should manufacture. */ -unsigned int dwarf_level = 0; +unsigned int dwarf_level = 4; #if defined OBJ_ELF || defined OBJ_MAYBE_ELF int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON; ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
(Adding OCaml author)
On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote:
> Hi Richard,
>
> On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> > On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > > Given these are .ml files I suspect it is not gcc, but some other
> > > code/DWARF generator issue. Maybe it does use the default
> > > (binutils)
> > > liker though?
> >
> > It uses its own DWARF generator but everything is linked together
> > using standard binutils (via GCC).
> >
> > > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so
> > > we
> > > can inspect it?
> >
> > I've uploaded the binary which I built on my own machine here:
> >
> > http://oirase.annexia.org/tmp/hacha.native
>
> This one looks OK.
>
> > plus some of the *.o files which went into it:
> >
> > http://oirase.annexia.org/tmp/myLexing.o
> > http://oirase.annexia.org/tmp/myStack.o
> > http://oirase.annexia.org/tmp/hacha.o
>
> And so do these.
I should probably add that I'm building these on my local machine
which isn't completely updated to Rawhide. I'm not sure whether or
not that will make a difference - I'm assuming _not_ for what the
OCaml compiler generates (since I'm running the latest of that), but
not sure about the rest of the toolchain. I'm using
binutils-2.34-3.fc32.x86_64.
> I also tried to do a mockbuild locally, and that one succeeded.
> Don't know what is different from the koji buildroot :{
>
> > I also saved an asm file from one of them which may be helpful:
> >
> > http://oirase.annexia.org/tmp/hacha.s
>
> So ml depends on binutils gas to generate the actual debuginfo.
> I assume it gets called with: as -g
> Is there a way to see how exactly gas is called (with which arguments)?
In fact it *isn't* passing -g to as:
$ /usr/bin/ocamlopt.opt -c -w +a-3-4-9-41-45-67 -g -annot -safe-string -o
hacha.cmx hacha.ml -S -verbose
+ as -o 'hacha.o' 'hacha.s'
Is this a problem? I sort of assumed that as would have nothing to do
with generating debug information, beyond what is contained explicitly
in the .s file itself.
> One of the gas 2.35 features is:
>
> * Add --gdwarf-5 option to the assembler to generate DWARF 5 debug output
> (if such output is being generated). Added the ability to generate
> version 5 .debug_line sections.
>
> Which is the version that just hit fedora rawhide. Maybe that changed
> something about the gas -g output as well?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi Richard,
On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > Given these are .ml files I suspect it is not gcc, but some other
> > code/DWARF generator issue. Maybe it does use the default
> > (binutils)
> > liker though?
>
> It uses its own DWARF generator but everything is linked together
> using standard binutils (via GCC).
>
> > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so
> > we
> > can inspect it?
>
> I've uploaded the binary which I built on my own machine here:
>
> http://oirase.annexia.org/tmp/hacha.native
This one looks OK.
> plus some of the *.o files which went into it:
>
> http://oirase.annexia.org/tmp/myLexing.o
> http://oirase.annexia.org/tmp/myStack.o
> http://oirase.annexia.org/tmp/hacha.o
And so do these.
I also tried to do a mockbuild locally, and that one succeeded.
Don't know what is different from the koji buildroot :{
> I also saved an asm file from one of them which may be helpful:
>
> http://oirase.annexia.org/tmp/hacha.s
So ml depends on binutils gas to generate the actual debuginfo.
I assume it gets called with: as -g
Is there a way to see how exactly gas is called (with which arguments)?
One of the gas 2.35 features is:
* Add --gdwarf-5 option to the assembler to generate DWARF 5 debug output
(if such output is being generated). Added the ability to generate
version 5 .debug_line sections.
Which is the version that just hit fedora rawhide. Maybe that changed
something about the gas -g output as well?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote: > > On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > > > with: > > > > > > error: Empty %files file > > > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list > > > > > > However it works when I build locally: > > > > > > $ rpm -qlp > > > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64 > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml > > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml > > > [etc] > > > > > > There's an earlier error which occurs in the Koji build which doesn't > > > occur for me locally but looks related: > > > > > > Dwarf Error: wrong version in compilation unit header (is 0, should be > > > 2, 3, 4 or 5) [in module > > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] > > > gdb-add-index: No index was created for > > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha > > > gdb-add-index: [Was there no debuginfo? Was there already an index?] > > > > > > Did something change with DWARF or gdb in Rawhide that we should be > > > aware of? Obviously these are not C code and OCaml has its own DWARF > > > generator. > > > > I think mjw is tracking something like this yesterday, but it was aarch64. > > I'm > > going to be offline for a couple hours, but you might want to reach out to > > him > > and see if there's any useful state (on cc) > > This looks unrelated to what I was looking at, which was indeed aarch64 > specific (but doesn't actually seem to be impacting the mass rebuild): > https://bugzilla.redhat.com/show_bug.cgi?id=1861423 > > The above happens if none of the debuginfo could be read at all, so no > source files could be extracted. > > Given these are .ml files I suspect it is not gcc, but some other > code/DWARF generator issue. Maybe it does use the default (binutils) > liker though? It uses its own DWARF generator but everything is linked together using standard binutils (via GCC). > Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we > can inspect it? I've uploaded the binary which I built on my own machine here: http://oirase.annexia.org/tmp/hacha.native plus some of the *.o files which went into it: http://oirase.annexia.org/tmp/myLexing.o http://oirase.annexia.org/tmp/myStack.o http://oirase.annexia.org/tmp/hacha.o I also saved an asm file from one of them which may be helpful: http://oirase.annexia.org/tmp/hacha.s Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
Hi, On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote: > On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > > with: > > > > error: Empty %files file > > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list > > > > However it works when I build locally: > > > > $ rpm -qlp > > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm > > /usr/src/debug/hevea-2.34-7.fc33.x86_64 > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml > > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml > > [etc] > > > > There's an earlier error which occurs in the Koji build which doesn't > > occur for me locally but looks related: > > > > Dwarf Error: wrong version in compilation unit header (is 0, should be 2, > > 3, 4 or 5) [in module > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] > > gdb-add-index: No index was created for > > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha > > gdb-add-index: [Was there no debuginfo? Was there already an index?] > > > > Did something change with DWARF or gdb in Rawhide that we should be > > aware of? Obviously these are not C code and OCaml has its own DWARF > > generator. > > I think mjw is tracking something like this yesterday, but it was aarch64. > I'm > going to be offline for a couple hours, but you might want to reach out to him > and see if there's any useful state (on cc) This looks unrelated to what I was looking at, which was indeed aarch64 specific (but doesn't actually seem to be impacting the mass rebuild): https://bugzilla.redhat.com/show_bug.cgi?id=1861423 The above happens if none of the debuginfo could be read at all, so no source files could be extracted. Given these are .ml files I suspect it is not gcc, but some other code/DWARF generator issue. Maybe it does use the default (binutils) liker though? Is there a way to extract the /usr/bin/hacha from the BUILDROOT so we can inspect it? Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: No debugsource generated, weird DWARF errors
On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > with: > > error: Empty %files file > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list > > However it works when I build locally: > > $ rpm -qlp > /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm > /usr/src/debug/hevea-2.34-7.fc33.x86_64 > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml > /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml > [etc] > > There's an earlier error which occurs in the Koji build which doesn't > occur for me locally but looks related: > > Dwarf Error: wrong version in compilation unit header (is 0, should be 2, > 3, 4 or 5) [in module > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] > gdb-add-index: No index was created for > /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha > gdb-add-index: [Was there no debuginfo? Was there already an index?] > > Did something change with DWARF or gdb in Rawhide that we should be > aware of? Obviously these are not C code and OCaml has its own DWARF > generator. I think mjw is tracking something like this yesterday, but it was aarch64. I'm going to be offline for a couple hours, but you might want to reach out to him and see if there's any useful state (on cc) Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
No debugsource generated, weird DWARF errors
https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails with: error: Empty %files file /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list However it works when I build locally: $ rpm -qlp /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm /usr/src/debug/hevea-2.34-7.fc33.x86_64 /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/auxx.ml /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/bibhva.ml /usr/src/debug/hevea-2.34-7.fc33.x86_64/_build/color.ml [etc] There's an earlier error which occurs in the Koji build which doesn't occur for me locally but looks related: Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 4 or 5) [in module /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha] gdb-add-index: No index was created for /builddir/build/BUILDROOT/hevea-2.34-7.fc33.x86_64/usr/bin/hacha gdb-add-index: [Was there no debuginfo? Was there already an index?] Did something change with DWARF or gdb in Rawhide that we should be aware of? Obviously these are not C code and OCaml has its own DWARF generator. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
