Re: [PATCH] debuginfod-doc: PR27950 - Remove redanduncies in man page.
Hi Frank, On Fri, 2021-07-30 at 08:47 -0400, Frank Ch. Eigler wrote: > > aha, ok, I understand now. This makes testing in-tree a bit more > > difficult. So the .so ./debuginfod-client-config.7 does work if you > > got > > into the doc/ subdirectory, then man ./debuginfod-find.1 does show > > the > > included chunks. But for the installed tree it should be .so man7 > > debuginfod-client-config.7 ? > > It'd probably be ".so ../man7/debuginfod-client-config.7" or > something. I cannot find the canonical documentation on this, but it looks like the search path is the current directory plus MANPATH, so I am not sure .. would work. man7 (and I think it should be space, not slash) should work as long its parent is either the current directory or in the MANPATH. But all this is a little fuzzy. Maybe we need man1, man3, man7, etc subdirs in doc to make it also work in-tree (but then buildir != srcdir probably is still borken). It might be fine if it only works in the install tree though. Just don't know how to write tests to double check things are fine. > > That is interesting, then we could make debuginfod-client-config.7 > > into a real man page and include only the actual contents. I am not > > completely sure I understand how this works though. I hope there is > > some man/troff documentation that explains this trick? > > Documentation? Nah, let's reverse-engineer: > > NROFF CPP > > builtins.1: > > .nr zZ 1#define zZ 1 > .so bash.1 #include > > bash.1: > > .if \n(zZ=1 .ig zZ #ifndef zZ > [...][...] > .zZ #else > [...][...] OK, that looks workable (although slightly ugly). Alice, would you be able to rewrite the split man pages using the above trickery? Please do feel to ask for more info and we'll try to figure something out. Thanks, Mark
Re: [Bug debuginfod/27982] added DEBUGINFOD_MAXSIZE and DEBUGINFOD_MAXTIME
On Fri, 2021-07-30 at 09:39 -0400, Noah Sanci wrote: > Here is the real patch :). Looks good. Pushed. Thanks, Mark
[Bug libelf/28190] New: FAIL: run-backtrace-native.sh with glibc 2.34
https://sourceware.org/bugzilla/show_bug.cgi?id=28190
Bug ID: 28190
Summary: FAIL: run-backtrace-native.sh with glibc 2.34
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libelf
Assignee: unassigned at sourceware dot org
Reporter: mliska at suse dot cz
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
I see the following failure:
[ 349s] FAIL: run-backtrace-native.sh
[ 349s] =
[ 349s]
[ 349s] backtrace: backtrace.c:111: callback_verify: Assertion `symname &&
strcmp (symname, "raise") == 0' failed.
[ 349s] ./test-subr.sh: line 84: 13043 Aborted
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
[ 349s] backtrace-child: no main
[ 349s] FAIL run-backtrace-native.sh (exit status: 1)
If I see correctly, symname is pthread_kill@GLIBC_2.2.5 for frameno == 0.
--
You are receiving this mail because:
You are on the CC list for the bug.
Buildbot failure in Wildebeest Builder on whole buildset
The Buildbot has detected a new failure on builder elfutils-centos-x86_64 while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/1/builds/796 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: centos-x86_64 Build Reason: Blamelist: Noah Sanci BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
[Bug libelf/28190] FAIL: run-backtrace-native.sh with glibc 2.34
https://sourceware.org/bugzilla/show_bug.cgi?id=28190 richard.purdie at linuxfoundation dot org changed: What|Removed |Added CC||richard.purdie@linuxfoundat ||ion.org --- Comment #1 from richard.purdie at linuxfoundation dot org --- I can confirm that Yocto Project is seeing the same issue in its automated testing on aarch64 and x86_64 with glibc 2.34 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27277] Describe retrieved files when verbose
Hello,
The attached patch dumps the http headers retrieved from the
debuginfod server which a file was downloaded from. Some custom
headers are now returned such as X-FILE, X-FILE-SIZE, and X-ARCHIVE to
give some context about the downloaded files.
Noah Sanci
From dcbe8672d6be30f92ad8baa2fa157b9b7a551b48 Mon Sep 17 00:00:00 2001
From: Noah Sanci
Date: Wed, 28 Jul 2021 14:46:05 -0400
Subject: [PATCH] debuginfod: PR27277 - Describe retrieved files when verbose
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 this. We could support this in the webapi, and give
options to debuginfod-find and the client API to use it.
Instead of implementing a describe option, allow users, with enough
verbosity, to get a file description printed to the verbose output
stream upon retrieving a file. The HEAD operation is not supported in
this patch.
E.g output:
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 2428240
Cache-Control: public
Last-Modified: Sat, 15 May 2021 20:49:51 GMT
X-FILE-SIZE: 656906321
X-FILE: /usr/lib/debug/lib/modules/5.11.21-200.fc33.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko.debug
X-ARCHIVE: kernel-debuginfo-5.11.21-200.fc33.x86_64.rpm
Content-Type: application/octet-stream
Date: Tue, 03 Aug 2021 18:50:36 GMT
https://sourceware.org/bugzilla/show_bug.cgi?id=27277
Signed-off-by: Noah Sanci
---
debuginfod/ChangeLog | 16 ++
debuginfod/debuginfod-client.c | 58 --
debuginfod/debuginfod-find.c | 3 ++
debuginfod/debuginfod.cxx | 11 +++
debuginfod/debuginfod.h.in | 3 ++
debuginfod/libdebuginfod.map | 3 ++
doc/ChangeLog | 6
doc/debuginfod-find.1 | 3 +-
tests/ChangeLog| 6
tests/run-debuginfod-find.sh | 19 ++-
10 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index 9e82d78d..4297b088 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,19 @@
+2021-08-02 Noah Sanci
+
+ PR27277
+ * debuginfod-client.c (debuginfod_client): New field winning_headers.
+ (handle_data): New field response_data.
+ (header_callback): Store received headers in response_data.
+ (debuginfod_query_server): Activate CURLOPT_HEADERFUNCTION.
+ Save winning response_data.
+ (debuginfod_get_response_headers): Return the winning headers.
+ * debuginfod.h.in: Declare new API function.
+ * libdebuginfod.map: Export it.
+ * debuginfod-find.c: Call it in verbose mode.
+ * debuginfod.cxx (handle_buildid_f_match): Add X-FILE and X-FILE-SIZE
+ http headers to response.
+ (handle_buildid_r_match): Add X-FILE, X-FILE-SIZE and X-ARCHIVE headers.
+
2021-07-26 Noah Sanci
PR27982
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 7d4b220f..5c2a646c 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -127,6 +127,7 @@ struct debuginfod_client
timeout or other info gotten from environment variables, the
handle data, etc. So those don't have to be reparsed and
recreated on each request. */
+ char * winning_headers;
};
/* The cache_clean_interval_s file within the debuginfod cache specifies
@@ -183,6 +184,8 @@ struct handle_data
to the cache. Used to ensure that a file is not downloaded from
multiple servers unnecessarily. */
CURL **target_handle;
+ /* Response http headers for this client handle, sent from the server */
+ char *response_data;
};
static size_t
@@ -499,6 +502,33 @@ default_progressfn (debuginfod_client *c, long a, long b)
}
+static size_t
+header_callback (char * buffer, size_t size, size_t numitems, void * userdata)
+{
+ if (size != 1)
+return 0;
+ /* Temporary buffer for realloc */
+ char *temp = NULL;
+ size_t userlen = 0;
+ if (*(char**)userdata == NULL)
+{
+ temp = malloc(numitems+1);
+ if (temp == NULL)
+return 0;
+ memset(temp, '\0', numitems+1);
+}
+ else
+{
+ userlen = strlen(*(char**)userdata);
+ temp = realloc(*(char**)userdata, userlen + numitems + 1);
+ if (temp == NULL)
+ return 0;
+}
+ strncat(temp, buffer, numitems);
+ *(char**)userdata = temp;
+ return numitems;
+}
+
/* Query each of the server URLs found in $DEBUGINFOD_URLS for the file
with the specified build-id, type (debuginfo, executable or source)
and filename. filename may be NULL. If found, return a file
@@ -936,10 +966,13 @@ debuginfod_query_server (debuginfod_client *c,
curl_easy_setopt (data[i].handle, CURLOPT_LOW_SPEED_LIMIT,
100 * 1024L);
}
+ data[i].response_data = NULL;
curl_easy_setopt(data[i].handle, CURLOPT_FILETIME, (long) 1);
curl_easy_setopt(data[i].handle, CURLOPT_FOLLOWLOCATION, (long) 1);
curl_easy_setopt(data[i].handle, CURLO
[Bug libelf/28190] FAIL: run-backtrace-native.sh with glibc 2.34
https://sourceware.org/bugzilla/show_bug.cgi?id=28190 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-04 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Mark Wielaard --- This comes from the following glibc commit: commit f779b1efb35fe141e47952af3ac7f0540acca401 Author: Adhemerval Zanella Date: Mon Dec 7 16:21:55 2020 -0300 nptl: Implement raise in terms of pthread_kill Now that pthread_kill is provided by libc.so it is possible to implement the generic POSIX implementation as 'pthread_kill(pthread_self(), sig)'. For Linux implementation, pthread_kill read the targeting TID from the TCB. For raise, this it not possible because it would make raise fail when issue after vfork (where creates the resulting process has a different TID from the parent, but its TCB is not updated as for pthread_create). To make raise use pthread_kill, it is make usable from vfork by getting the target thread id through gettid syscall. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Before raise simply called the (tg)kill syscall directly. Now we have an extra frame in the backtrace. -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] tests: Allow an extra pthread_kill frame in backtrace tests
glibc 2.34 calls pthread_kill from the raise function. Before raise
directly called the (tg)kill syscall. So allow pthread_kill to be the
first frame in a backtrace where raise is expected. Also change some
asserts to fprintf plus abort to make it more clear why the testcase
fails.
https://sourceware.org/bugzilla/show_bug.cgi?id=28190
Signed-off-by: Mark Wielaard
---
tests/ChangeLog | 6 +
tests/backtrace.c | 62 +--
2 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index 3409..3bfd1ca2 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,9 @@
+2021-08-04 Mark Wielaard
+
+ PR28190
+ * backtrace.c (callback_verify): Check for pthread_kill as first
+ frame. Change asserts to fprintf plus abort.
+
2021-07-26 Noah Sanci
PR27982
diff --git a/tests/backtrace.c b/tests/backtrace.c
index 36c8b8c4..779335df 100644
--- a/tests/backtrace.c
+++ b/tests/backtrace.c
@@ -97,6 +97,9 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr pc,
static bool reduce_frameno = false;
if (reduce_frameno)
frameno--;
+ static bool pthread_kill_seen = false;
+ if (pthread_kill_seen)
+frameno--;
if (! use_raise_jmp_patching && frameno >= 2)
frameno += 2;
const char *symname2 = NULL;
@@ -107,11 +110,27 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr
pc,
&& (strcmp (symname, "__kernel_vsyscall") == 0
|| strcmp (symname, "__libc_do_syscall") == 0))
reduce_frameno = true;
+ else if (! pthread_kill_seen && symname
+ && strncmp (symname, "pthread_kill",
+ strlen ("pthread_kill")) == 0)
+ pthread_kill_seen = true;
else
- assert (symname && strcmp (symname, "raise") == 0);
+ {
+ if (!symname || strcmp (symname, "raise") != 0)
+ {
+ fprintf (stderr,
+ "case 0: expected symname 'raise' got '%s'\n", symname);
+ abort ();
+ }
+ }
break;
case 1:
- assert (symname != NULL && strcmp (symname, "sigusr2") == 0);
+ if (symname == NULL || strcmp (symname, "sigusr2") != 0)
+ {
+ fprintf (stderr,
+ "case 1: expected symname 'sigusr2' got '%s'\n", symname);
+ abort ();
+ }
break;
case 2: // x86_64 only
/* __restore_rt - glibc maybe does not have to have this symbol. */
@@ -120,11 +139,21 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr
pc,
if (use_raise_jmp_patching)
{
/* Verify we trapped on the very first instruction of jmp. */
- assert (symname != NULL && strcmp (symname, "jmp") == 0);
+ if (symname == NULL || strcmp (symname, "jmp") != 0)
+ {
+ fprintf (stderr,
+ "case 3: expected symname 'raise' got '%s'\n", symname);
+ abort ();
+ }
mod = dwfl_addrmodule (dwfl, pc - 1);
if (mod)
symname2 = dwfl_module_addrname (mod, pc - 1);
- assert (symname2 == NULL || strcmp (symname2, "jmp") != 0);
+ if (symname2 == NULL || strcmp (symname2, "jmp") != 0)
+ {
+ fprintf (stderr,
+ "case 3: expected symname2 'jmp' got '%s'\n", symname2);
+ abort ();
+ }
break;
}
FALLTHROUGH;
@@ -137,11 +166,22 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr
pc,
duplicate_sigusr2 = true;
break;
}
- assert (symname != NULL && strcmp (symname, "stdarg") == 0);
+ if (symname == NULL || strcmp (symname, "stdarg") != 0)
+ {
+ fprintf (stderr,
+ "case 4: expected symname 'stdarg' got '%s'\n", symname);
+ abort ();
+ }
break;
case 5:
/* Verify we trapped on the very last instruction of child. */
- assert (symname != NULL && strcmp (symname, "backtracegen") == 0);
+ if (symname == NULL || strcmp (symname, "backtracegen") != 0)
+ {
+ fprintf (stderr,
+ "case 5: expected symname 'backtracegen' got '%s'\n",
+ symname);
+ abort ();
+ }
mod = dwfl_addrmodule (dwfl, pc);
if (mod)
symname2 = dwfl_module_addrname (mod, pc);
@@ -151,7 +191,15 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr
pc,
// instructions or even inserts some padding instructions at the end
// (which apparently happens on ppc64).
if (use_raise_jmp_patching)
-assert (symname2 == NULL || strcmp (symname2, "backtracegen") != 0);
+ {
+ if (symname2 != NULL && strcmp (symname2, "backtracegen") == 0)
+ {
+ fprintf (stderr,
+ "use_raise_jmp_patching didn't expect symname2 "
+ "'backtracegen'\n");
[Bug libelf/28190] FAIL: run-backtrace-native.sh with glibc 2.34
https://sourceware.org/bugzilla/show_bug.cgi?id=28190 --- Comment #3 from Mark Wielaard --- Proposed fix: https://sourceware.org/pipermail/elfutils-devel/2021q3/004016.html -- You are receiving this mail because: You are on the CC list for the bug.
