[Bug translator/25549] Systemtap unable to find many probe points available in code compiled with LTO enable

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25549

--- Comment #12 from Mark Wielaard <mark at klomp dot org> ---
(In reply to William Cohen from comment #11)
> I have put the f30 ld binary and associated debuginfo file in 
> 
> http://people.redhat.com/wcohen/pr25549/ld/
> 
> The ld built with lto and its debuginfo file is in:
> 
> http://people.redhat.com/wcohen/pr25549/ld.lto/

Thanks, but do you also have a build before debug splitting by rpmbuild?
Asking because I just saw an issue reported against debugedit with LTO builds:
https://github.com/rpm-software-management/rpm/issues/1207
Or do you have at least the build.log so we can see if there are any issues
reported during the build?

BTW. ld-2.31.1-29.fc30_gcc_o2__g_.x86_64.debug seems to use an alt (multi dwz)
file (not included in the downloads), but
ld-2.31.1-29.fc30_gcc_o2_lto_g_.x86_64.debug doesn't. Did the lto version not
get through dwz or was there some other issue that prevented the alt file from
being created?

Also, is it possible to rebuild with GCC10, older gcc seem to have some
lto/debuginfo quirks.

> As far as probe points there are probe points missing for entire files
> (ignore the '-./' at the beginning the - is from the diff and the "./" was
> substitution to make the remove to original full path to make comparing
> things from build directories more comparable):
> 
> -./adler32.c
> -./aligned_buffer.h
> -./allocator.h
> -./alloc_traits.h
> -./argv.c
> -./basic_ios.h
> -./binary.h
> -./char_traits.h
> -./compress.c
> -./copy-relocs.h
> -./cp-demangle.c
> -./cp-demint.c
> -./cplus-dem.c
> -./crc32.c
> -./d-demangle.c
> -./debug.h
> -./deflate.c
> -./defstd.cc
> -./../elfcpp/elfcpp_file.h
> -./../elfcpp/elfcpp.h
> -./../elfcpp/elfcpp_swap.h
> -./errors.h
> -./fcntl2.h
> -./filename_cmp.c
> -./fileread.h
> -./freebsd.h
> -./fstream
> -./functional_hash.h
> -./gc.cc
> -./hex.c
> -./inffast.c
> -./inflate.c
> -./inftrees.c
> -./ios_base.h
> -./istream
> -./lbasename.c
> -./list.tcc
> -./locale_facets.h
> -./lrealpath.c
> -./md5.c
> -./move.h
> -./new_allocator.h
> -./predefined_ops.h
> -./reloc.h
> -./reloc-types.h
> -./rust-demangle.c
> -./script-sections.h
> -./sha1.c
> -./stat.h
> -./stdio2.h
> -./stdlib.h
> -./stl_construct.h
> -./stl_function.h
> -./stl_iterator_base_funcs.h
> -./stl_set.h
> -./stl_tempbuf.h
> -./stl_uninitialized.h
> -./streambuf
> -./string_fortified.h
> -./string.h
> -./stringpool.h
> -./tls.h
> -./trees.c
> -./unistd.h
> -./unlink-if-ordinary.c
> -./utility
> -./xexit.c
> -./xmalloc.c
> -./xmemdup.c
> -./xstrdup.c
> -./zutil.c

All these seem to come from "outside" the binutils gold build dir. It might be
that there is some confusion in the DWARF about the combined code. These files
have most likely been build inside different working dirs (comp_dirs). So it
might be that with lto/debuginfo merging they come out against the wrong
(relative) build dir?

-- 
You are receiving this mail because:
You are the assignee for the bug.