On 24/02/2021 14:16, Mark Wielaard wrote:>>> -#define NO_RESIZING 0u
-#define ALLOCATING_MEMORY 1u
-#define MOVING_DATA 3u
-#define CLEANING 2u
+#define NO_RESIZING 0x0
+#define ALLOCATING_MEMORY 0x1
+#define MOVING_DATA 0x3
+#define CLEANING 0x2
Nope, same result. :(
Hmm
Hi -
> FWIW I looked a little at unifying these. For example,
> bfdopncls.c:bfd_get_alt_debug_link_info could look at both the build-id
> and .debug_sup.
>
> But, this seemed a bit weird. What if both appear and they are
> different? Then a single API isn't so great -- you want to check the ID
On Thu, Feb 25, 2021 at 11:42:45AM -0500, Frank Ch. Eigler via Dwz wrote:
> > FWIW I looked a little at unifying these. For example,
> > bfdopncls.c:bfd_get_alt_debug_link_info could look at both the build-id
> > and .debug_sup.
> >
> > But, this seemed a bit weird. What if both appear and they
Hi -
> For dwz --dwarf-5, if it produced a .note.gnu.build-id, it would produce
> the same one, but I thought that if I produced that, then consumers could
> keep using that instead of .debug_sup which is the only thing defined
> in the standard, so in the end dwz --dwarf-5 only produces .debug_su
Hi Mark,
$ git clone git://sourceware.org/git/dwz.git
$ cd dwz
$ ./configure
$ make
$ cp dwz one
$ cp dwz two
$ dwz --dwarf-5 -m sup one two
Thanks. Using those files as a guide I have added some initial support for
displaying and following .debug_sup sections to readelf and objdump.
Cheers
Hi -
Committed as obvious.
Author: Frank Ch. Eigler
Date: Thu Feb 25 14:04:20 2021 -0500
debuginfod: filter webapi for bad keywords early
Prevent some unnecessary processing of user data and
keep invalid request types out of metrics.
Signed-off-by: Frank Ch. Eigler
