bugs in external debug info support in libbacktrace
Hey Ian, others,
I was made aware that libbacktrace got support for external debug info with
[1], great work! I have just synced the latest libbacktrace into heaptrack [2]
in a local branch and played around with it and noticed two limitations:
[1]: https://github.com/gcc-mirror/gcc/commit/
b919941efc58035debbcf69b645c072b7dd6ba4e
[2]: https://github.com/KDE/heaptrack
a) elf_open_debugfile_by_debuglink checks the crc, even if it is not provided
by the debug file. I.e. I have a file where `debuglink_crc == 0`, but the
got_crc calculated from elf_crc32_file is non-zero. I have patched this
locally with the following to make it work for me:
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index 06823fcf59b..24bf58728fd 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -1005,7 +1005,7 @@ elf_open_debugfile_by_debuglink (struct backtrace_state
*state,
if (ddescriptor < 0)
return -1;
- got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
+ got_crc = debuglink_crc ? elf_crc32_file (state, ddescriptor,
error_callback, data) : 0;
if (got_crc != debuglink_crc)
{
backtrace_close (ddescriptor, error_callback, data);
b) elf_add guards the code to inspect the symtab-shndx with a `&& !debuginfo`
check in loc 2797. This results in all files with separate debug info yielding
`found_sym = 0` when calling elf_add, and symbol resolution is broken.
Personally I have patched this check out to make symbol resolution work for
me:
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index 06823fcf59b..6876bd3ed8e 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -2794,7 +2794,7 @@ elf_add (struct backtrace_state *state, const char
*filename, int descriptor,
if (symtab_shndx == 0)
symtab_shndx = dynsym_shndx;
- if (symtab_shndx != 0 && !debuginfo)
+ if (symtab_shndx != 0)
{
const b_elf_shdr *symtab_shdr;
unsigned int strtab_shndx;
Could you please check whether the two patches above could be upstreamed?
Thanks a lot for your work
--
Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
Re: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
On 11/26/2017 11:09 PM, Marek wrote: Hi, while compiling 7.2.0 im getting the following: cc1: error: no include path in which to search for stdc-predef.h cc1: note: self-tests are not enabled in this build This doesn't appear to be a build error. Configure runs the compiler to check for features, and if a check fails, then the feature is disabled. This is normal, and nothing to worry about. Though the message is unusual. If the compiler is the one you just built, there might be something wrong with it. Or there might be a minor configure script bug. configure: error: in `/run/media/void/minnow/build/gcc-7.2.0/x86_64-lfs-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [Makefile:12068: configure-target-libgcc] Error 1 make: *** [Makefile:880: all] Error 2 This is the real build error. You need to look at the config.log file in the directory where configure failed to see what the problem is. This is usually a build environment problem of some sort. If gcc is able to recognize between sources in one dir and objects in another dir Yes. The usual way to configure gcc is something like mkdir build cd build ../gcc/configure Jim
Re: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
N.B. the gcc@gcc.gnu.org mailing list is not for support. For help building or using GCC use the gcc-h...@gcc.gnu.org mailing list (see https://gcc.gnu.org/lists.html for information on the lists and what's on-topic). On 27 November 2017 at 20:23, Jim Wilson wrote: > On 11/26/2017 11:09 PM, Marek wrote: >> >> Hi, >> >> while compiling 7.2.0 im getting the following: >> >> cc1: error: no include path in which to search for stdc-predef.h >> cc1: note: self-tests are not enabled in this build > > > This doesn't appear to be a build error. Configure runs the compiler to > check for features, and if a check fails, then the feature is disabled. This > is normal, and nothing to worry about. Though the message is unusual. If > the compiler is the one you just built, there might be something wrong with > it. Or there might be a minor configure script bug. > >> configure: error: in >> `/run/media/void/minnow/build/gcc-7.2.0/x86_64-lfs-linux-gnu/libgcc': >> configure: error: cannot compute suffix of object files: cannot compile >> See `config.log' for more details. >> make[1]: *** [Makefile:12068: configure-target-libgcc] Error 1 >> make: *** [Makefile:880: all] Error 2 > > > This is the real build error. You need to look at the config.log file in > the directory where configure failed to see what the problem is. This is > usually a build environment problem of some sort. There's a FAQ entry about this error, please read it: https://gcc.gnu.org/wiki/FAQ#configure_suffix >> If gcc is able to recognize between sources in one dir and objects in >> another dir > > > Yes. The usual way to configure gcc is something like > mkdir build > cd build > ../gcc/configure See https://gcc.gnu.org/wiki/InstallingGCC for more information, including how to avoid the error above.
