Re: [PATCHv2] libelf, readelf, elflint: Add RELR support
Hi, On Fri, 2023-08-25 at 01:33 +0200, Mark Wielaard wrote: > Handle RELR as defined here: > https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/YT2RrjpMAwAJ > > Introduce new ELF_T_RELR Elf_Type and handle it for SHT_RELR. Check > various properties in elflint. Print RELR relocations in > readelf. Just the entries with -U. Just the addresses with -N. And > addresses plus symbol/offsets by default. > > Also add a test to check that gelf.h works with the system elf.h. > > * libebl/eblsectiontypename.c (ebl_section_type_name): Add RELR > to knownstype. > * libelf/elf32_updatenull.c (updatenull_wrlock): Handle > sh_entsize for SHT_RELR. > * libelf/gelf.h (GElf_Relr): New typedef for Elf64_Relr. > * libelf/gelf_fsize.c (__libelf_type_sizes): Add ELF_T_RELR. > * libelf/gelf_xlate.c (__elf_xfctstom): Likewise. > * libelf/gelf_xlate.h: Add RELR as FUNDAMENTAL. > * libelf/libelf.h (Elf_Type): Add ELF_T_RELR. Add RELR > defines/typedefs if undefined in system elf.h. > * libelf/libelfP.h: Define ELF32_FSZ_RELR and ELF64_FSZ_RELR. > * src/elflint.c (check_reloc_shdr): Check she_entsize for > ELF_T_RELR. > (check_relr): New function. > (check_dynamic): Handle DT_RELR. > (special_sections): Add SHT_RELR. > (check_sections): Call check_relr. > * src/readelf.c (print_relocs): Also accept a Dwfl_Module. > (handle_relocs_relr): New function. > (print_dwarf_addr): Make static and declare early. > (process_elf_file): Pass dwflmod to print_relocs. > (handle_dynamic): Handle DT_RELRSZ and DTRELRENT. > * system-elf-gelf-test.c: New test. > * Makefile.am (TESTS): Add system-elf-gelf-test. > (check_PROGRAMS): Likewise. > (system_elf_gelf_test_CPPFLAGS): New variable. > (system_elf_gelf_test_LDADD): Likewise. > > https://sourceware.org/bugzilla/show_bug.cgi?id=28495 > > Signed-off-by: Mark Wielaard > --- > > v2 > - Fix GElf_Relr typedef name > - Add RELR typedefs/defines if missing from system elf.h > - Add a system-elf-gelf-test I pushed this variant. The same, minus the new testcase has also been backported to Fedora rawhide. Cheers, Mark
[Bug tools/28495] Add support for SHT_RELR to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28495 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Mark Wielaard --- commit 39f2c500542f69c2f1a13fd0ae4eaa5778d2ed8d Author: Mark Wielaard Date: Sun Jul 23 23:14:31 2023 +0200 libelf, readelf, elflint: Add RELR support Handle RELR as defined here: https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/YT2RrjpMAwAJ Introduce new ELF_T_RELR Elf_Type and handle it for SHT_RELR. Check various properties in elflint. Print RELR relocations in readelf. Just the entries with -U. Just the addresses with -N. And addresses plus symbol/offsets by default. Also add a test to check that gelf.h works with the system elf.h. * libebl/eblsectiontypename.c (ebl_section_type_name): Add RELR to knownstype. * libelf/elf32_updatenull.c (updatenull_wrlock): Handle sh_entsize for SHT_RELR. * libelf/gelf.h (GElf_Relr): New typedef for Elf64_Relr. * libelf/gelf_fsize.c (__libelf_type_sizes): Add ELF_T_RELR. * libelf/gelf_xlate.c (__elf_xfctstom): Likewise. * libelf/gelf_xlate.h: Add RELR as FUNDAMENTAL. * libelf/libelf.h (Elf_Type): Add ELF_T_RELR. Add RELR defines/typedefs if undefined in system elf.h. * libelf/libelfP.h: Define ELF32_FSZ_RELR and ELF64_FSZ_RELR. * src/elflint.c (check_reloc_shdr): Check she_entsize for ELF_T_RELR. (check_relr): New function. (check_dynamic): Handle DT_RELR. (special_sections): Add SHT_RELR. (check_sections): Call check_relr. * src/readelf.c (print_relocs): Also accept a Dwfl_Module. (handle_relocs_relr): New function. (print_dwarf_addr): Make static and declare early. (process_elf_file): Pass dwflmod to print_relocs. (handle_dynamic): Handle DT_RELRSZ and DTRELRENT. * system-elf-gelf-test.c: New test. * Makefile.am (TESTS): Add system-elf-gelf-test. (check_PROGRAMS): Likewise. (system_elf_gelf_test_CPPFLAGS): New variable. (system_elf_gelf_test_LDADD): Likewise. https://sourceware.org/bugzilla/show_bug.cgi?id=28495 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204
--- Comment #28 from Mark Wielaard ---
(In reply to Ryan Goldberg from comment #27)
> (In reply to Mark Wielaard from comment #24)
> > BTW. How does this interact with the "section" queries?
> Since these aren't ima verifiable anyways wdyt of just skipping verification
> all together (i.e treat that query in the same way as the ignore policy)
Assuming ima verification is so one can be sure bits are what a distro really
distributes I don't think a default to ignore policy is useful. I think in
enforcing mode there is no good way to fetch just the section data and the
client has to fall back onto requesting the full executable or debuginfo file,
verify the ima signature, and then locally extract the section data (of course
this is somewhat inefficient).
> Tweaking the above to something like:
> 2008if(NULL != url_ima_policies && ignore !=
> url_ima_policies[committed_to] && NULL == section) { ... }
>
> (In reply to Mark Wielaard from comment #25)
> > Includes an "undefined" policy?
> Just used internally when parsing DEBUGINFOD_URLS
> > Is the k += DATA_SIZE correct? Can't pread return an n < DATA_SIZE?
> Fixed
> > If the cert_paths = strdup (...) fails cert_paths gets assigned a static
> > string?
> Fixed
Thanks. It would be good to post a patch with these fixes (maybe rebased to
current git trunk). So it is more clear what exact change you intent to commit.
> (In reply to Mark Wielaard from comment #26)
> > If we have an permissive mode then I think it should work like the selinux
> > permissive mode.
> > That is, it should always check the signature, but instead of failing with
> > EPERM, it should
> > always produce a warning (whether or not we are in verbose mode or not).
> I would be ok with this kind of permissive mode
This would have my preference too. Or just simply have either an ignore or
enforcing mode.
But from our discussion on irc I think Frank believes it is better to see
permissive mode as a kind of possible checksum mode. I am not sure about that
use case.
Given that we have reliable transports a checksum mode might be something for
the server to do (assuming the server doesn't trust its own storage). The
server could do an ima check before sending any file and simply don't sent it
if the ima check(sum) fails. This then would be independent of the client ima
check (enforced or not).
--
You are receiving this mail because:
You are on the CC list for the bug.
[PATCH 1/2] libelf: Sync elf.h from Glibc
Adds new LoongArch relocations. * elf.h: Update from glibc. Signed-off-by: Xi Ruoyao --- libelf/elf.h | 9 + 1 file changed, 9 insertions(+) diff --git a/libelf/elf.h b/libelf/elf.h index 89fc8021..9c51073f 100644 --- a/libelf/elf.h +++ b/libelf/elf.h @@ -4205,6 +4205,15 @@ enum #define R_LARCH_TLS_GD_HI20 98 #define R_LARCH_32_PCREL 99 #define R_LARCH_RELAX 100 +#define R_LARCH_DELETE 101 +#define R_LARCH_ALIGN 102 +#define R_LARCH_PCREL20_S2 103 +#define R_LARCH_CFA 104 +#define R_LARCH_ADD6 105 +#define R_LARCH_SUB6 106 +#define R_LARCH_ADD_ULEB128 107 +#define R_LARCH_SUB_ULEB128 108 +#define R_LARCH_64_PCREL 109 /* ARC specific declarations. */ -- 2.42.0
[PATCH 2/2] backends: Update list of LoongArch relocations
* backends/loongarch_reloc.def: Add DELETE, ALIGN, PCREL20_S2, CFA, ADD6, SUB6, ADD_ULEB128, SUB_ULEB128, 64_PCREL. Signed-off-by: Xi Ruoyao --- backends/loongarch_reloc.def | 9 + 1 file changed, 9 insertions(+) diff --git a/backends/loongarch_reloc.def b/backends/loongarch_reloc.def index fd204924..a39eefd9 100644 --- a/backends/loongarch_reloc.def +++ b/backends/loongarch_reloc.def @@ -119,3 +119,12 @@ RELOC_TYPE (TLS_GD_PC_HI20,REL) RELOC_TYPE (TLS_GD_HI20, REL) RELOC_TYPE (32_PCREL, REL) RELOC_TYPE (RELAX, REL) +RELOC_TYPE (DELETE,REL) +RELOC_TYPE (ALIGN, REL) +RELOC_TYPE (PCREL20_S2,REL) +RELOC_TYPE (CFA, REL) +RELOC_TYPE (ADD6, REL) +RELOC_TYPE (SUB6, REL) +RELOC_TYPE (ADD_ULEB128, REL) +RELOC_TYPE (SUB_ULEB128, REL) +RELOC_TYPE (64_PCREL, REL) -- 2.42.0
Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T
Hi, On Fri, 2023-03-31 at 12:50 +0800, lilydjwg via Elfutils-devel wrote: > On Thu, Mar 30, 2023 at 01:24:13PM -0400, Frank Ch. Eigler wrote: > > > The written_size is actual file size (uncompressed), but IIUC > > > Content-Length is the compressed size if Content-Encoding says the > > > content is compressed. I haven't seen any compressed responses with > > > Content-Length, but from the spec I don't read they are not allowed. > > > > OK, so to spell out the hypothetical problem: what if a httpd server > > does send back a Content-Length: response header for a compressed > > file, and we use that as the denominator for progress reporting. If > > we use the decompressed actual file length as numerator, we'd go over > > 100%. > > > > Then ISTM a simpler way to handle this would be to say that if the > > x-debuginfod-size: response header is found (as denominator), then go > > ahead and use the actual data[committed_to].written_size (as > > numerator). Don't even try the CURLINFO_SIZE* queries then. > > It's not tried in that case. size_compressed indicates where the total > size is from and those CURLINFO_SIZE* is skipped. Maybe I should rename > the variable to something else (it's not always compressed). > > Or do you mean that you want to always use written_size even when the > progress may go beyond 100%? What is the status of this patch/discussion? Thanks, Mark
Re: [PATCH 2/2] backends: Update list of LoongArch relocations
On Tue, 2023-08-29 at 21:14 +0800, Xi Ruoyao via Elfutils-devel wrote: > * backends/loongarch_reloc.def: Add DELETE, ALIGN, PCREL20_S2, > CFA, ADD6, SUB6, ADD_ULEB128, SUB_ULEB128, 64_PCREL. Thanks, looks correct. Pushed, Mark
Re: [PATCH 1/2] libelf: Sync elf.h from Glibc
On Tue, 2023-08-29 at 21:14 +0800, Xi Ruoyao via Elfutils-devel wrote: > Adds new LoongArch relocations. > > * elf.h: Update from glibc. Thanks, matches current glibc elf/elf.h. Pushed, Mark
☠ Buildbot (Sourceware): elfutils - failed test (failure) (master)
A new failure has been detected on builder elfutils-centos-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/39/builds/216 Build state: failed test (failure) Revision: 2ba424d65adca45b799a3973d43ccaf4002cb833 Worker: centos-x86_64 Build Reason: (unknown) Blamelist: Xi Ruoyao Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/6/logs/stdio - warnings (2): https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/6/logs/warnings__2_ - 7: make check ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/18/logs/stdio A restored build has been detected on builder elfutils-gentoo-sparc while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/225/builds/88 Build state: build successful Revision: 2ba424d65adca45b799a3973d43ccaf4002cb833 Worker: gentoo-sparc Build Reason: (unknown) Blamelist: Mark Wielaard , Xi Ruoyao Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/225/builds/88/steps/6/logs/warnings__3_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/build
Re: ☠ Buildbot (Sourceware): elfutils - failed test (failure) (master)
Hi, On Tue, 2023-08-29 at 14:04 +, builder--- via Elfutils-devel wrote: > A new failure has been detected on builder elfutils-centos-x86_64 while > building elfutils. > > Full details are available at: > https://builder.sourceware.org/buildbot/#builders/39/builds/216 > > Build state: failed test (failure) > Revision: 2ba424d65adca45b799a3973d43ccaf4002cb833 > Worker: centos-x86_64 > Build Reason: (unknown) > Blamelist: Xi Ruoyao This isn't caused by that commit. > - 7: make check ( failure ) > Logs: > - stdio: > https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/7/logs/stdio > - test-suite.log: > https://builder.sourceware.org/buildbot/#builders/39/builds/216/steps/7/logs/test-suite_log Unfortunately this happens occasionally on this centos7 x86_64 setup. The issue is that only the "child" thread can be unwound, but not the main thread. I don't know why however, since it doesn't happen always. It could be that the kernel generates a bad core file or that the main thread is in a weird state (without unwind cfi) after the clone. Cheers, Mark
☺ Buildbot (Sourceware): elfutils - build successful (master)
A restored build has been detected on builder elfutils-centos-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/39/builds/217 Build state: build successful Revision: 9c41344c968a9c4b9bf539b09ed522e5ada9deb1 Worker: centos-x86_64 Build Reason: (unknown) Blamelist: Xi Ruoyao Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/6/logs/stdio - warnings (2): https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/6/logs/warnings__2_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/217/steps/18/logs/stdio
[Bug debuginfod/30809] New: improve debuginfod-client progress callback parameters
https://sourceware.org/bugzilla/show_bug.cgi?id=30809 Bug ID: 30809 Summary: improve debuginfod-client progress callback parameters Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- For the compressed case, we can/should compute proper download-progress metrics even of compressed transfers, by periodic fstat() of the output file. https://inbox.sourceware.org/elfutils-devel/20230330172413.gg30...@redhat.com/ -- You are receiving this mail because: You are on the CC list for the bug.
PR30809, was Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T
Hi -
> What is the status of this patch/discussion?
U forgot about it. But that's OK, filed PR30809, and wrote &
tested this little patch:
commit 3ef3fab0d64c89a52dd6e2ce0d01dd5e713d7b5a
Author: Frank Ch. Eigler
Date: Tue Aug 29 14:08:04 2023 -0400
PR30809: improve debuginfod client progress-callback parameters
* debuginfod-client.c (debuginfod_query_server): Use fstat(3)
of the file handle being downloaded into as the preferred
source of download progress.
Tested by hand, as the testsuite doesn't have enough machinery to
simulate compressed vs. uncompressed service. Hand testing with
(unmodified) fedora-38 gdb and debuginfod-find shows dramatically
improved progress displays: all have quantitative figures when
fetching from real (unmodified) upstream servers.
Signed-off-by: Frank Ch. Eigler
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index d92d8d62c982..6882cb190d3c 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -1533,6 +1533,20 @@ debuginfod_query_server (debuginfod_client *c,
long pa = loops; /* default param for progress callback */
if (target_handle) /* we've committed to a server; report its
download progress */
{
+ /* PR30809: Check actual size of cached file. This same
+ fd is shared by all the multi-curl handles (but only
+ one will end up writing to it). Another way could be
+ to tabulate totals in debuginfod_write_callback(). */
+ struct stat cached;
+ int statrc = fstat(fd, &cached);
+ if (statrc == 0)
+pa = (long) cached.st_size;
+ else
+{
+ /* Otherwise, query libcurl for its tabulated total.
+ However, that counts http body length, not
+ decoded/decompressed content length, so does not
+ measure quite the same thing as dl. */
CURLcode curl_res;
#if CURL_AT_LEAST_VERSION(7, 55, 0)
curl_off_t dl;
@@ -1549,7 +1563,7 @@ debuginfod_query_server (debuginfod_client *c,
if (curl_res == 0)
pa = (dl >= (double)(LONG_MAX+1UL) ? LONG_MAX : (long)dl);
#endif
-
+}
}
if ((*c->progressfn) (c, pa, dl_size == -1 ? 0 : dl_size))
Re: PR30809, was Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T
Hi Frank, On Tue, Aug 29, 2023 at 02:33:07PM -0400, Frank Ch. Eigler wrote: > commit 3ef3fab0d64c89a52dd6e2ce0d01dd5e713d7b5a > Author: Frank Ch. Eigler > Date: Tue Aug 29 14:08:04 2023 -0400 > > PR30809: improve debuginfod client progress-callback parameters > > * debuginfod-client.c (debuginfod_query_server): Use fstat(3) > of the file handle being downloaded into as the preferred > source of download progress. > > Tested by hand, as the testsuite doesn't have enough machinery to > simulate compressed vs. uncompressed service. Hand testing with > (unmodified) fedora-38 gdb and debuginfod-find shows dramatically > improved progress displays: all have quantitative figures when > fetching from real (unmodified) upstream servers. > > Signed-off-by: Frank Ch. Eigler Very nice and simple. Looks good. Thanks, Mark
[Bug debuginfod/30809] improve debuginfod-client progress callback parameters
https://sourceware.org/bugzilla/show_bug.cgi?id=30809 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- > commit 3ef3fab0d64c89a52dd6e2ce0d01dd5e713d7b5a > Author: Frank Ch. Eigler > Date: Tue Aug 29 14:08:04 2023 -0400 > > PR30809: improve debuginfod client progress-callback parameters -- You are receiving this mail because: You are on the CC list for the bug.
