platform_external_elfutils/libdwfl, branch master

libdwfl: do not dlopen libdebuginfod.so in --disable-libdebuginfod mode

2020-08-31T08:39:35+00:00

debuginfod-client.c used to try to dlopen libdebuginfod.so even if
libdebuginfod was completely disabled using --disable-libdebuginfod.

Fix this by disabling build of debuginfod-client.c and disabling all
__libdwfl_debuginfod_* invocations in --disable-libdebuginfod mode.

Signed-off-by: Dmitry V. Levin 
Signed-off-by: Mark Wielaard

libdwfl, src: Replace some asserts with proper check or error messages.

2020-07-19T12:17:19+00:00

library code really shouldn't assert and for utilities a proper
error message is better than crashing with an assert.

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

Signed-off-by: Mark Wielaard

libdwfl: read_address should use increasing address in intuit_kernel_bounds

2020-06-28T13:27:25+00:00

In kernels from 4.14 up to 4.19 in /proc/kallsyms there are special
__entry_SYSCALL_64_trampoline symbols. The problem is that they come
after the last kernel address, but before the module addresses.
And they are (much) smaller than the start address we found. This
confuses intuit_kernel_bounds and makes it fail.

Make sure to check read_address returns an increasing address when
searching for the end.

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

Reported-by: Vitaly Chikunov 
Signed-off-by: Mark Wielaard

libdwfl: Flag an error if CIE return_address_register is invalid.

2020-06-19T17:58:11+00:00

If the CIE return address register is invalid (unknown) for the
architecture immediately flag an error and return.

Signed-off-by: Mark Wielaard

libdwfl: When we find a compressed image, use that, don't search for others

2020-06-19T17:03:14+00:00

We try to find a compressed vmlinux image ending with either .gz, bz2 or
xz. Stop searching if we find one. Otherwise we will leak a file descriptor
for an earlier one we opened.

Signed-off-by: Mark Wielaard

libdwfl: Return failure from dwfl_standard_find_debuginfo for NULL module.

2020-05-14T12:30:57+00:00

GCC10 -fanalyzer plus -flto notices that some functions called by
dwfl_standard_find_debuginfo check that the given module isn't NULL,
but others expect it to be non-NULL. Just return a failure immediately
when a NULL mod is passed to dwfl_standard_find_debuginfo.

Signed-off-by: Mark Wielaard

libdwfl: Cleanup user_core resources on failure in dwfl_core_file_report.

2020-05-14T12:30:57+00:00

GCC10 -fanalyzer noticed that we allocate, but don't always cleanup the
dwfl->user_core if it wasn't set yet on error. In theory dwfl_module_end
should take care of it, but it is cleaner and less confusing to just do
it here.

Signed-off-by: Mark Wielaard

libdwfl: Handle debugaltlink in dwfl_standard_find_debuginfo.

2020-04-30T22:00:28+00:00

When we fall back to the debuginfod client then we need to do the
same trick we do for local lookups in dwfl_build_id_find_debuginfo.
If the debug file (dw) is already set, then we must be looking for
the altfile. But we cannot use the actual file/path name given as
hint. We'll have to lookup the alt file "build-id". Because the
debuginfod client only handles build-ids.

Previously we would use the build-id of the main file which meant
the debuginfod client would give us another copy of the debug file,
which would then be set as its own altfile. This caused lots of
confusion...

Signed-off-by: Mark Wielaard

libdwfl: Fix double free on failure path in gzip.c.

2020-04-26T00:37:16+00:00

GCC10 -fanalyzer found a double free when openstream failed. When
openstream fails __libdw_gunzip will call fail, which frees the
state->buffer. But openstream can call zlib_fail, which will also
call fail. Instead of calling zlib_fail, just return the error
that zlib_fail would have returned.

Signed-off-by: Mark Wielaard

libdwfl: Initialize bits to NULL in dwfl_standard_find_debuginfo for LTO.

2020-04-16T15:45:31+00:00

GCC10 LTO is too smart (and somewhat cryptic):

    find-debuginfo.c: In function ‘dwfl_standard_find_debuginfo’:
    debuginfod-client.c:85:8: error: ‘bits’ may be used uninitialized
    in this function [-Werror=maybe-uninitialized]
    find-debuginfo.c:360:24: note: ‘bits’ was declared here
    lto1: all warnings being treated as errors

So it inlines __libdwfl_debuginfod_find_debuginfo into
dwfl_standard_find_debuginfo and since it cannot see into the
function pointer (*fp_debuginfod_find_debuginfo), it assumes that
build_id_bit (== bits in dwfl_standard_find_debuginfo) will be used
by the called function and it might not be initialized.
But if you read the code the there is a check for build_id_len > 0
to see whether bits is or isn't initialized before using bits.
But gcc isn't smart enough to figure that out.

Maybe that actually should be an heuristic gcc lto should use.
If the callchain I am inlining is so deep that I cannot figure out
maybe-uninitialized variables anymore I should stop inlining.

For now just help GCC out and initialize bits to NULL.

Signed-off-by: Mark Wielaard