Re: Remove misleading XOR
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. :( Hmmm. I am not sure why that doesn't work. What if you make them explicitly unsinged (adding u at the end). Or does it simply ignore the values and just warn because it sees the macro name and not an explicit number? I opened https://reviews.llvm.org/D97445 upstream and it looks like the behavior with both LHS and RHS being a macro is just a bug. If that patch gets accepted, it will fix the problems in the elfutils code base. Would still be nice to have a work-around in the meantime I think. - Timm -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
Re: build-ids, .debug_sup and other IDs
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 > corresponding to whatever was in the original file. If both appear and are different, can we characterize the elf file as malformed? Does our current tooling produce such files? If it's an abnormality (requires special elf manipulation or whatever), we could avoid bending backward for this case, and tune the tools to the Normal. > [...] > I suppose a distro can ensure that the IDs are always equal. Via debugedit for example? > Maybe debuginfod could also just require this. Or debuginfod could export the content under -both- IDs, if there were two valid candidates, and just go with the flow. Let the clients choose which ID they prefer to look up by. - FChE
Re: build-ids, .debug_sup and other IDs
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 are > > different? Then a single API isn't so great -- you want to check the ID > > corresponding to whatever was in the original file. > > If both appear and are different, can we characterize the elf file as > malformed? Unsure, the DWARF spec only talks about .debug_sup, the NOTE is a GNU extension. > Does our current tooling produce such files? If it's an dwz without --dwarf-5 produces .gnu_debugaltlink in the referrers and .note.gnu.build-id in the supplemental object file. 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_sup on both the referrers side and on the side of supplemental object file as DWARF specifies. Jakub
Re: build-ids, .debug_sup and other IDs
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_sup > on both the referrers side and on the side of supplemental object file > as DWARF specifies. Right, but build-ids are still in normal binaries -- just not the dwz-commonized files created by "dwz --dwarf-5"? So our toolchains still process build-ids routinely for all the other uses. By omitting the build-id on the dwz-generated files, we're forcing a flag day on all our consumer tools. (Does dwz'd dwarf5 even work on gdb etc. now?) ISTM tool backward compatibility is more important, so I would suggest dwz generate -both- identifiers. - FChE
Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
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 Nick
patch obv: debuginfod metrics hygiene
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
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index a66ded383a9f..98089b2d97bc 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2021-02-25 Frank Ch. Eigler
+
+ * debuginfod.cxx (handler_cb): Filter webapi for bad
+ artifacttype keywords early for metric hygiene.
+
2021-02-14 Frank Ch. Eigler
* debuginfod.cxx (main -U): Use bsdtar unconditionally. Also map
diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
index 6fdaf60e6632..2aecc0494062 100644
--- a/debuginfod/debuginfod.cxx
+++ b/debuginfod/debuginfod.cxx
@@ -1587,6 +1587,8 @@ handle_buildid (MHD_Connection* conn,
else if (artifacttype == "source") atype_code = "S";
else throw reportable_exception("invalid artifacttype");
+ inc_metric("http_requests_total", "type", artifacttype);
+
if (atype_code == "S" && suffix == "")
throw reportable_exception("invalid source suffix");
@@ -1936,7 +1938,6 @@ handler_cb (void * /*cls*/,
suffix = url_copy.substr(slash3); // include the slash in the
suffix
}
- inc_metric("http_requests_total", "type", artifacttype);
// get the resulting fd so we can report its size
int fd;
r = handle_buildid(connection, buildid, artifacttype, suffix, &fd);
diff --git a/tests/ChangeLog b/tests/ChangeLog
index 889f5066d537..9444712889a6 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,7 @@
+2021-02-25 Frank Ch. Eigler
+
+ * run-debuginfod-find.sh: Add bad webapi artifacttype test.
+
2021-02-17 Frank Ch. Eigler
* run-debuginfod-find.sh: Tweak wait_ready() to also print -vvv log of
diff --git a/tests/run-debuginfod-find.sh b/tests/run-debuginfod-find.sh
index 1ae63e0ee79a..bcca61301b2b 100755
--- a/tests/run-debuginfod-find.sh
+++ b/tests/run-debuginfod-find.sh
@@ -493,6 +493,9 @@ curl -s http://127.0.0.1:$PORT1/metrics | grep
'scanned_bytes_total'
curl -s http://127.0.0.1:$PORT2/badapi > /dev/null || true
curl -s http://127.0.0.1:$PORT2/buildid/deadbeef/debuginfo > /dev/null || true
+# Confirm bad artifact types are rejected without leaving trace
+curl -s http://127.0.0.1:$PORT2/buildid/deadbeef/badtype > /dev/null || true
+(curl -s http://127.0.0.1:$PORT2/metrics | grep 'badtype') && false
# Corrupt the sqlite database and get debuginfod to trip across its errors
