From: Omar Sandoval
Currently, the address ranges for segments reported with
dwfl_report_segment and modules are stored in the same sorted array.
This requires complicated logic in reify_segments for splitting up
existing segments and inserting into the table, which can have quadratic
runtime in
From: Omar Sandoval
dwfl_addrmodule matches a module if the address lies within low_addr and
high_addr. This is incorrect for relocatable files, particularly kernel
modules: sections of different modules can be intermingled within the
same range of addresses. Instead, we should index each section
From: Omar Sandoval
Currently, __libdwfl_relocate_value doesn't distinguish between unloaded
sections and sections loaded at address zero. This has a few
consequences:
* relocate.c attempts relocation on unloaded sections when we don't have
anything meaningful to relocate against.
* derelocate
From: Omar Sandoval
dwfl_report_segment has some logic that detects when a segment is
contiguous with the previously reported segment, in which case it's
supposed to coalesce them. However, in this case, it actually returns
without updating the segment array at all. As far as I can tell, this
has
From: Omar Sandoval
Hello,
I recently encountered a bug that dwfl_addrmodule doesn't work correctly
for Linux kernel modules. This is because each section of a kernel
module is allocated independently, so sections from different kernel
modules may be intermixed. For example:
# cd /sys/modules
#
On Tue, Dec 10, 2019 at 05:28:19PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> dwfl_report_segment() has some logic that detects when a segment is
> contiguous with the previously reported segment, in which case it's
> supposed to coalesce them. However, in this case, it actually return
From: Omar Sandoval
If CFLAGS contains -Wno-error, then the check for -D_FORTIFY_SOURCE=2
won't fail when appropriate. E.g., compiling with:
./configure CFLAGS='-Wno-error -O0' &&
Results in a flood of "_FORTIFY_SOURCE requires compiling with
optimization (-O)" warnings.
Make sure we add -We
From: Omar Sandoval
elfutils is compiled with -Wimplicit-fallthrough=5, so the fallthrough
comment in i386_lex.c (generated by flex) doesn't prevent the implicit
fallthrough warning. Add -Wno-implicit-fallthrough to i386_lex_CFLAGS.
Signed-off-by: Omar Sandoval
---
libcpu/ChangeLog | 4
From: Omar Sandoval
Hello,
This small series fixes a couple of issues I encountered when building
elfutils. Patch 1 fixes an issue when compiling with CFLAGS='-Wno-error
-O0'. Patch 2 gets rid of a warning.
Thanks!
Omar Sandoval (2):
configure: Fix -D_FORTIFY_SOURCE=2 check when CFLAGS cont
On Mon, 2019-12-09 at 19:49 +0100, Mark Wielaard wrote:
> If the debuginfod-client isn't configured we should do as little
> as possible. Simply return early with ENOSYS if no servers are
> configured. This means we won't check
>
> This does change the behavior of the debuginfod_find calls slightl
Hi Frank,
On Fri, 2019-12-06 at 22:03 -0500, Frank Ch. Eigler wrote:
> @@ -851,7 +867,11 @@ handle_buildid_r_match (int64_t b_mtime,
> > >return 0;
> > > }
> > >
> > > - string popen_cmd = string("rpm2cpio " + shell_escape(b_source0));
> > > + string archive_decoder = "/dev/null";
Hi,
On Fri, 2019-12-06 at 16:17 -0500, Frank Ch. Eigler wrote:
> Presenting testing for the debuginfod .deb/.ddeb support patch, after
> finding a good debian-packaging tutorial, and generating a workable
> basic set of test deb's on a Ubuntu box.
According to Matthias on irc there should be no d
Hi,
On Fri, Dec 06, 2019 at 05:22:41PM +0100, Mark Wielaard wrote:
> We really need build-ids for various things. If the system compiler
> doesn't generate build-ids warn and generate them anyway for both the
> binaries and the tests.
I pushed this to master with one change:
> +# We really want
13 matches
Mail list logo
