Re: [PATCH] findtextrel: do not use unbound alloca

Hi Dmitry, On Mon, Sep 06, 2021 at 06:00:00PM +, Dmitry V. Levin wrote: > This fixes the following compilation warning: > > findtextrel.c:184:1: warning: stack usage might be unbounded [-Wstack-usage=] And it simplifies the code a lot IMHO. Looks good, please apply. Thanks, Mark

Re: [PATCH 2/2] Use xasprintf instead of asprintf followed by error(EXIT_FAILURE)

Hi Dmitry, On Mon, Sep 06, 2021 at 10:00:00AM +, Dmitry V. Levin wrote: > + * color.c (parse_opt): Replace asprintf followed by error(EXIT_FAILURE) > + with xasprintf. > + * objdump.c (show_disasm): Replace asprintf followed by > + error(EXIT_FAILURE) with xasprintf. > + *

Re: [PATCH 1/2] Introduce xasprintf

Hi Dmitry, On Mon, Sep 06, 2021 at 10:00:00AM +, Dmitry V. Levin wrote: > Similar to other x* functions, xasprintf is like asprintf except that > it dies in case of an error. Looks useful and the implementation seems correct. Please apply. Thanks, Mark

Re: [PATCH] Remove redundant casts of memory allocating functions returning void *

Hi Dmitry, On Mon, Sep 06, 2021 at 08:00:00AM +, Dmitry V. Levin wrote: > Return values of functions returning "void *", e.g. calloc, malloc, > realloc, xcalloc, xmalloc, and xrealloc, do not need explicit casts. This does make the code slightly more readable. And the cast doesn't really add

Re: [PATCH] src: add -Wno-error=stack-usage= to AM_LDFLAGS

Hi Dmitry, On Mon, Sep 06, 2021 at 03:59:05AM +0300, Dmitry V. Levin wrote: > While -Wstack-usage= is already excluded from AM_CFLAGS for various > tools in src using *_no_Wstack_usage variables, this obviously does not > help when LTO is enabled, so add -Wno-error=stack-usage= to AM_LDFLAGS > for

Re: Adding a new section to an ELF file aborts with Assertion `shdr != NULL'

Hi Alex, On Sat, Sep 04, 2021 at 08:38:51AM +, Alexander Egorenkov via Elfutils-devel wrote: > i'm facing an issue with libelf when i try to add a new section to an > ELF file. > > How to reproduce the issue: > 1. Create a simple ELF file with libelf containing only 2 sections, NULL and > a

Re: [Bug debuginfod/27277] Describe retrieved files when verbose

Hi Noah, Looks like I reviewed a slightly older version earlier. Could you merge the reviewes/changes for both version in a new version of this patch? On Fri, Aug 27, 2021 at 02:38:27PM -0400, Noah Sanci via Elfutils-devel wrote: > From ed7638571f188e346dd466c195b9ebda028d1c65 Mon Sep 17 00:00:0

[Bug libdw/28220] dwarf_location_attr returns high-bit junk from .debug_addr when fetching 32-bit addresses

https://sourceware.org/bugzilla/show_bug.cgi?id=28220 --- Comment #5 from Mark Wielaard --- Proposed patch and testcase: https://sourceware.org/pipermail/elfutils-devel/2021q3/004149.html -- You are receiving this mail because: You are on the CC list for the bug.

[PATCH] libdw: set address size, offset size and version on fake CUs

There are three "fake CUs" that are associated with .debug_loc, .debug_loclist and .debug_addr. These fake CUs are used for "fake attributes" to provide values that are stored in these sections instead of in the .debug_info section. These fake CUs didn't have the address size, offset size and DWAR

[PATCH] lib: Fix unused parameter warning in lib/error.c

Mark the errnum parameter with __attribute__((unused)). Signed-off-by: Colin Cross --- lib/error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/error.c b/lib/error.c index 75e964fd..651a0f3d 100644 --- a/lib/error.c +++ b/lib/error.c @@ -35,7 +35,7 @@ unsigned int e

[Bug libdw/28220] dwarf_location_attr returns high-bit junk from .debug_addr when fetching 32-bit addresses

https://sourceware.org/bugzilla/show_bug.cgi?id=28220 --- Comment #4 from Mark Wielaard --- Turns out we could have caught this with the varlocs testcase. Before the fix: $ for i in testfile-vars-*.o; do echo $i; tests/varlocs --debug --exprlocs -e $i | grep exprloc; done testfile-vars-clang-dwa

Re: [Bug debuginfod/27277] Describe retrieved files when verbose

Hi Noah, On Wed, 2021-08-25 at 14:08 -0400, Noah Sanci via Elfutils-devel wrote: > There appear to exist use cases that intend to simply check for the > existence of content in a debuginfod server, without actually > downloading it. In HTTP land, the HEAD operation is the natural > expression of

Re: [Bug debuginfod/28034] client-side %-escape url characters

Hi Noah, This looks good, but the description is not really what the patch does. It is part of the PR28034 fix, but repeating that problem statement doesn't really make clear what this patch is about. Could explain in the commit message that curl_easy_escape () also escapes '/' to '%2F' and that w

[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives

https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #3 from Frank Ch. Eigler --- > How would this be used together with debuginfod? > Where/how would the user get the signatures >From debuginfod, possibly via additional response headers, when extracting files from IMA-signed archiv