Re: [PATCHv2] support ZSTD compression algorithm
On 12/19/22 16:16, Mark Wielaard wrote: > Hi Martin, > > On Mon, 2022-12-19 at 15:21 +0100, Martin Liška wrote: + else +error (0, 0, "Couldn't get chdr for section %zd", ndx); >>> >>> Shouldn't this error be fatal? >> >> What do you use for fatal errors? > > Depends a bit on context. It might be that this error isn't fatal, then > zero as first (status) argument is fine, just know that the program > will just continue. And it looked like not all callers were prepared > for this function to return with a bogus return value. > > If it is fatal then depending on context you either call error_exit (0, > "Couldn't get chdr for section %zd", ndx); [see system.h, this really > is just error (EXIT_FAILURE, 0, ...)] if the program needs to terminate > right now. > > Or you return a special value from the function (assuming all callers > check for an error here). And/Or if the program needs a cleanup you'll > goto cleanup (as is done in process_file). I think it's fine as we return UNSET in that case and the caller goes directly to cleanup (or abort is called for the second call site): enum ch_type schtype = get_section_chtype (scn, shdr, sname, ndx); if (schtype == UNSET) goto cleanup; Martin > > Cheers, > > Mark
Re: [PATCHv2] support ZSTD compression algorithm
On 12/19/22 16:09, Mark Wielaard wrote:
> Hi Martin,
>
> On Mon, 2022-12-19 at 15:19 +0100, Martin Liška wrote:
>> On 12/15/22 14:17, Mark Wielaard wrote:
>>> Is there a particular way you are running eu-readelf? Is it with
>>> generic -w or -a, or decoding a specific section type?
>>
>> Hello.
>>
>> $ LD_LIBRARY_PATH=./libelf ./src/readelf -w
>> ~/Programming/testcases/a.out
>>
>> where I get:
>>
>> ./src/readelf: cannot get debug context descriptor: No DWARF
>> information found
>>
>> DWARF section [37] '.debug_info' at offset 0x1ab2:
>> [Offset]
>> ./src/readelf: cannot get next unit: no error
>>
>> Call frame information section [13] '.eh_frame' at offset 0x4a8:
>> ...
>>
>>
>> t��o5��=I�iAp@aS^R/<�^�qi�ַp@
>
> [...]
>
>> So basically a garbage. And I don't know how to bail out properly?
>
> Aha. If you have that a.out somewhere I can take a look. I suspect this
> is because we expect all .debug sections to have been decompressed in
> libdw/dwarf_begin_elf.c, but that isn't really true, see check_section
> in that file which has:
>
> if ((shdr->sh_flags & SHF_COMPRESSED) != 0)
> {
> if (elf_compress (scn, 0, 0) < 0)
> {
> /* It would be nice if we could fail with a specific error.
> But we don't know if this was an essential section or not.
> So just continue for now. See also valid_p(). */
> return result;
> }
> }
Sure, there's a file example:
https://splichal.eu/tmp/zstd.out
$ ./src/readelf -Sz zstd.out
...
[35] .debug_abbrevPROGBITS 18b4 0177 0 C
0 0 1
[ELF ZSTD (2) 0318 1]
$ LD_LIBRARY_PATH=libelf/ ./src/readelf -w zstd.out
(prints garbage if not configured with zstd)
Please use code from my branch:
https://sourceware.org/git/?p=elfutils.git;a=shortlog;h=refs/heads/users/marxin/try-zstd-support-v2
Cheers,
Martin
>
> We should probably adjust valid_p so it produces a more appropriate
> error message and/or add additional checks in readlelf.c.
>
> But lets do that after this patch goes in.
>
> Cheers,
>
> Mark
[PATCH v4] Add support for Synopsys ARCv2 processors
There is no regression in tests for an x86_64 build, while the new hello_arc_hs4.ko is added as well. This is the only meaningful test that I could add at the moment, given the features supported by this port. $ cat tests/test-suite.log == elfutils 0.188: tests/test-suite.log == # TOTAL: 236 # PASS: 235 # SKIP: 1 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: run-lfs-symbols.sh LFS testing is irrelevant on this system SKIP run-lfs-symbols.sh (exit status: 77) $ cat tests/run-strip-reloc.sh.log runtest hello_i386.ko runtest hello_x86_64.ko runtest hello_ppc64.ko runtest hello_s390.ko runtest hello_aarch64.ko runtest hello_m68k.ko runtest hello_riscv64.ko runtest hello_csky.ko runtest hello_arc_hs4.ko<-- [ new ARC HS4 test ] runtest /home/shahab/pahole_pkg/elfutils-git/bld_arc/src/strip runtest /home/shahab/pahole_pkg/elfutils-git/bld_arc/src/strip.o runtest strip-uncompressed.o runtest strip-compressed.o runtest testfile-debug-rel-ppc64.o runtest testfile-debug-rel-ppc64-z.o runtest testfile-debug-rel-ppc64-g.o PASS run-strip-reloc.sh (exit status: 0) Signed-off-by: Shahab Vahedi --- Changelog: v4: - Add EM_ARCV2 to valid_e_machine[] in src/elflint.c. - Add a link to ARCv3 elf document in arc_init.c. - Update ChangeLogs. v3: - Drop libelf/elf.h changes now that they're synced from glibc. - Drop src/elflint.c changes as EM_ARC was already in valid_e_machine[]. - Add test for ARC HS4 in run-strip-reloc. - Update ChangeLogs and a few more cosemitic changes. - Reword the commit message. v2: - Add ChangeLog entries. - Reduce number of changes in libelf/elf.h - Reword the commit message. backends/ChangeLog | 9 backends/Makefile.am | 6 ++- backends/arc_init.c| 59 + backends/arc_reloc.def | 87 + backends/arc_symbol.c | 81 ++ libebl/ChangeLog | 5 +++ libebl/eblopenbackend.c| 2 + src/ChangeLog | 4 ++ src/elflint.c | 1 + tests/ChangeLog| 6 +++ tests/Makefile.am | 1 + tests/hello_arc_hs4.ko.bz2 | Bin 0 -> 15004 bytes tests/run-strip-reloc.sh | 4 +- 13 files changed, 262 insertions(+), 3 deletions(-) create mode 100644 backends/arc_init.c create mode 100644 backends/arc_reloc.def create mode 100644 backends/arc_symbol.c create mode 100644 tests/hello_arc_hs4.ko.bz2 diff --git a/backends/ChangeLog b/backends/ChangeLog index 5813ddcc..13afc116 100644 --- a/backends/ChangeLog +++ b/backends/ChangeLog @@ -1,3 +1,12 @@ +2022-12-21 Shahab Vahedi + + * Makefile.am (modules): Add arc. + (arc_SRCS): Added. + (libebl_backends_a_SOURCES): Append arc_SRCS. + * arc_init.c: New file. + * arc_reloc.def: New file. + * arc_symbol.c: New file. + 2022-12-02 Hengqi Chen * Makefile.am (modules): Add loongarch. diff --git a/backends/Makefile.am b/backends/Makefile.am index 0824123d..f373e5fb 100644 --- a/backends/Makefile.am +++ b/backends/Makefile.am @@ -37,7 +37,7 @@ AM_CPPFLAGS += -I$(top_srcdir)/libebl -I$(top_srcdir)/libasm \ noinst_LIBRARIES = libebl_backends.a libebl_backends_pic.a modules = i386 sh x86_64 ia64 alpha arm aarch64 sparc ppc ppc64 s390 \ - m68k bpf riscv csky loongarch + m68k bpf riscv csky loongarch arc i386_SRCS = i386_init.c i386_symbol.c i386_corenote.c i386_cfi.c \ i386_retval.c i386_regs.c i386_auxv.c \ @@ -98,12 +98,14 @@ csky_SRCS = csky_attrs.c csky_init.c csky_symbol.c csky_cfi.c \ loongarch_SRCS = loongarch_init.c loongarch_symbol.c +arc_SRCS = arc_init.c arc_symbol.c + libebl_backends_a_SOURCES = $(i386_SRCS) $(sh_SRCS) $(x86_64_SRCS) \ $(ia64_SRCS) $(alpha_SRCS) $(arm_SRCS) \ $(aarch64_SRCS) $(sparc_SRCS) $(ppc_SRCS) \ $(ppc64_SRCS) $(s390_SRCS) \ $(m68k_SRCS) $(bpf_SRCS) $(riscv_SRCS) $(csky_SRCS) \ - $(loongarch_SRCS) + $(loongarch_SRCS) $(arc_SRCS) libebl_backends_pic_a_SOURCES = am_libebl_backends_pic_a_OBJECTS = $(libebl_backends_a_SOURCES:.c=.os) diff --git a/backends/arc_init.c b/backends/arc_init.c new file mode 100644 index ..a7cceceb --- /dev/null +++ b/backends/arc_init.c @@ -0,0 +1,59 @@ +/* Initialization of ARC specific backend library. + Copyright (C) 2022 Synopsys Inc. + This file is part of elfutils. + + This file is free software; you can redistribute it and/or modify + it under the terms of either + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at + y
Re: [PATCH 1/1] support cross compilation
Hi, It looks like I missed this. Sorry. On Wed, 2021-05-26 at 19:34 +0300, Petr Ovtchenkov wrote: > On Wed, 26 May 2021 12:41:51 -0300 > Érico Nogueira wrote: > > > > > Yes, we really cross. > > It doesn't matter because > > > We always use the release tarballs, which already have the %_dis.h > > files. This explains why we haven't hit any issues. > > > > Anyway, couldn't you (re)use the distribution tarball generation > > stuff > > for cross setups from git master? > > I can. But I haven't problems with building it "directly from VCS" > too, > as you see. Nevertheless there are opinion that code from VCS > could be smoothly building without procedures behind scene. Isn't it simpler to first do a local make dist and then build cross from that? Cheers, Mark
[Bug general/28891] Cross compilation for ARM fails when trying to run i386_gendis
https://sourceware.org/bugzilla/show_bug.cgi?id=28891 --- Comment #2 from Mark Wielaard --- So a solution for people trying to do cross builds directly from git might simply be to do a make dist first and then do a cross from that? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29434] Memory leak in `dwarf_getscopes`
https://sourceware.org/bugzilla/show_bug.cgi?id=29434 --- Comment #16 from Mark Wielaard --- Sorry this is a bit difficult to debug. Would you be able to show the start of the log? It should show how you are calling dwarf_getscopes. I think I have found the RHEL7 glibc debug file. So I can match up some of the DIE offsets, but I have some trouble understanding what is going on. It would also be helpful to see the other log statements in dwarf_getscopes to understand what the first and second calls to __libdw_visit_scopes have as arguments and return value. -- You are receiving this mail because: You are on the CC list for the bug.
Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
On 12/21/22 12:15, buil...@sourceware.org wrote: > A failed build has been detected on builder elfutils-try-debian-armhf while > building elfutils. > > Full details are available at: > https://builder.sourceware.org/buildbot/#builders/201/builds/47 > > Build state: failed compile (failure) > Revision: 1b845fdf4ca4d5367969cc5b33cbfa60338cf51b > Worker: debian-armhf > Build Reason: (unknown) > Blamelist: Martin Liska > > Steps: > > - 0: worker_preparation ( success ) > > - 1: set package name ( success ) > > - 2: git checkout ( success ) > Logs: > - stdio: > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/2/logs/stdio > > - 3: autoreconf ( success ) > Logs: > - stdio: > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/3/logs/stdio > > - 4: configure ( success ) > Logs: > - stdio: > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/4/logs/stdio > > - 5: get version ( success ) > Logs: > - stdio: > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/5/logs/stdio > - property changes: > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/5/logs/property_changes > > - 6: make ( failure ) > Logs: > - stdio: > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/6/logs/stdio > Mark, do you know what can be wrong about the configure test: elf_compress.c: In function ‘__libelf_compress_zstd’: elf_compress.c:205:3: error: unknown type name ‘ZSTD_EndDirective’; did you mean ‘ZSTD_DDict’? ZSTD_EndDirective mode = ZSTD_e_continue; ^ ZSTD_DDict elf_compress.c:205:28: error: ‘ZSTD_e_continue’ undeclared (first use in this function) ZSTD_EndDirective mode = ZSTD_e_continue; ^~~ elf_compress.c:205:28: note: each undeclared identifier is reported only once for each function it appears in elf_compress.c:237:9: error: ‘ZSTD_e_end’ undeclared (first use in this function); did you mean ‘ZSTD_DDict’? mode = ZSTD_e_end; ^~ ZSTD_DDict elf_compress.c:243:17: error: implicit declaration of function ‘ZSTD_compressStream2’; did you mean ‘ZSTD_compressStream’? [-Werror=implicit-function-declaration] size_t ret = ZSTD_compressStream2 (cctx, &ob, &ib, mode); ^~~~ ZSTD_compressStream Thanks, Martin
Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
Hi Martin,
On Wed, 2022-12-21 at 15:20 +0100, Martin Liška wrote:
> On 12/21/22 12:15, buil...@sourceware.org wrote:
> > A failed build has been detected on builder elfutils-try-debian-
> > armhf while building elfutils.
> >
> > Full details are available at:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47
> >
> > Build state: failed compile (failure)
> > Revision: 1b845fdf4ca4d5367969cc5b33cbfa60338cf51b
> > Worker: debian-armhf
> > Build Reason: (unknown)
> > Blamelist: Martin Liska
> >
> > Steps:
> >
> > - 0: worker_preparation ( success )
> >
> > - 1: set package name ( success )
> >
> > - 2: git checkout ( success )
> > Logs:
> > - stdio:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/2/logs/stdio
> >
> > - 3: autoreconf ( success )
> > Logs:
> > - stdio:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/3/logs/stdio
> >
> > - 4: configure ( success )
> > Logs:
> > - stdio:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/4/logs/stdio
> >
> > - 5: get version ( success )
> > Logs:
> > - stdio:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/5/logs/stdio
> > - property changes:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/5/logs/property_changes
> >
> > - 6: make ( failure )
> > Logs:
> > - stdio:
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/6/logs/stdio
> >
>
> Mark, do you know what can be wrong about the configure test:
>
> elf_compress.c: In function ‘__libelf_compress_zstd’:
> elf_compress.c:205:3: error: unknown type name ‘ZSTD_EndDirective’;
> did you mean ‘ZSTD_DDict’?
>ZSTD_EndDirective mode = ZSTD_e_continue;
>^
>ZSTD_DDict
> elf_compress.c:205:28: error: ‘ZSTD_e_continue’ undeclared (first use
> in this function)
>ZSTD_EndDirective mode = ZSTD_e_continue;
> ^~~
> elf_compress.c:205:28: note: each undeclared identifier is reported
> only once for each function it appears in
> elf_compress.c:237:9: error: ‘ZSTD_e_end’ undeclared (first use in
> this function); did you mean ‘ZSTD_DDict’?
> mode = ZSTD_e_end;
> ^~
> ZSTD_DDict
> elf_compress.c:243:17: error: implicit declaration of function
> ‘ZSTD_compressStream2’; did you mean ‘ZSTD_compressStream’? [-
> Werror=implicit-function-declaration]
> size_t ret = ZSTD_compressStream2 (cctx, &ob, &ib, mode);
> ^~~~
> ZSTD_compressStream
Heay cool, the try buildbot worked.
The configure test seems to succeed (from the configure log):
checking for library containing ZSTD_compressStream2... -lzstd
Unfortunately buildbot itself doesn't show the config.log.
Trying to get that...
configure:6961: checking for library containing ZSTD_compressStream2
configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
-fsanitize=undefined
-fno-sanitize-recover -fsanitize=address -fno-sanitize-
recover conftest.c -llz
ma -lbz2 >&5
/usr/bin/ld: /tmp/ccKZnuYA.o: in function `main':
/var/lib/buildbot/workers/wildebeest/elfutils-try-debian-
armhf/build/conftest.c:
30: undefined reference to `ZSTD_compressStream2'
collect2: error: ld returned 1 exit status
configure:6992: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "elfutils"
| #define PACKAGE_TARNAME "elfutils"
| #define PACKAGE_VERSION "0.188"
| #define PACKAGE_STRING "elfutils 0.188"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla";
| #define PACKAGE_URL "http://elfutils.org/";
| #define PACKAGE "elfutils"
| #define VERSION "0.188"
| #define DEFAULT_AR_DETERMINISTIC false
| #define HAVE_VISIBILITY 1
| #define HAVE_STDATOMIC_H 1
| #define _FILE_OFFSET_BITS 64
| #define CHECK_UNDEFINED 1
| #define USE_ZLIB 1
| #define USE_BZLIB 1
| #define USE_LZMA 1
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char ZSTD_compressStream2 ();
| int
| main ()
| {
| return ZSTD_compressStream2 ();
| ;
| return 0;
| }
configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
-fsanitize=undefined
-fno-sanitize-recover -fsanitize=address -fno-sanitize-
recover conftest.c -lzs
td -llzma -lbz2 >&5
configure:6992: $? = 0
configure:7009: result: -lzstd
ehe? So it fails and then succeeds anyway?
Strangely the same happens for the other compression library checks...
lzma_auto_decoder and BZ2_bzdopen
I don't fully understand this. Oddly the same seems to happen locally
on my x86_64 box. So maybe the configure macros we have been using have
always been bad/broken?
Cheers,
Mark
Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
Hi - > [...] > Unfortunately buildbot itself doesn't show the config.log. > Trying to get that... Ah darn. It would have been saved in bunsen, but the buildbot configuration means that a make-stage failure means it won't even try. - FChE
Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
Hi,
On Wed, 2022-12-21 at 15:42 +0100, Mark Wielaard wrote:
>
> Unfortunately buildbot itself doesn't show the config.log.
> Trying to get that...
>
> configure:6961: checking for library containing ZSTD_compressStream2
> configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
> -fsanitize=undefined
> -fno-sanitize-recover -fsanitize=address -fno-sanitize-
> recover conftest.c -llz
> ma -lbz2 >&5
> /usr/bin/ld: /tmp/ccKZnuYA.o: in function `main':
> /var/lib/buildbot/workers/wildebeest/elfutils-try-debian-
> armhf/build/conftest.c:
> 30: undefined reference to `ZSTD_compressStream2'
> collect2: error: ld returned 1 exit status
> configure:6992: $? = 1
> configure: failed program was:
> > /* confdefs.h */
> > #define PACKAGE_NAME "elfutils"
> > #define PACKAGE_TARNAME "elfutils"
> > #define PACKAGE_VERSION "0.188"
> > #define PACKAGE_STRING "elfutils 0.188"
> > #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla";
> > #define PACKAGE_URL "http://elfutils.org/";
> > #define PACKAGE "elfutils"
> > #define VERSION "0.188"
> > #define DEFAULT_AR_DETERMINISTIC false
> > #define HAVE_VISIBILITY 1
> > #define HAVE_STDATOMIC_H 1
> > #define _FILE_OFFSET_BITS 64
> > #define CHECK_UNDEFINED 1
> > #define USE_ZLIB 1
> > #define USE_BZLIB 1
> > #define USE_LZMA 1
> > /* end confdefs.h. */
> >
> > /* Override any GCC internal prototype to avoid an error.
> >Use char because int might match the return type of a GCC
> >builtin and then its argument prototype would still apply. */
> > #ifdef __cplusplus
> > extern "C"
> > #endif
> > char ZSTD_compressStream2 ();
> > int
> > main ()
> > {
> > return ZSTD_compressStream2 ();
> > ;
> > return 0;
> > }
>
> configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
> -fsanitize=undefined
> -fno-sanitize-recover -fsanitize=address -fno-sanitize-
> recover conftest.c -lzs
> td -llzma -lbz2 >&5
> configure:6992: $? = 0
> configure:7009: result: -lzstd
>
> ehe? So it fails and then succeeds anyway?
>
> Strangely the same happens for the other compression library
> checks...
> lzma_auto_decoder and BZ2_bzdopen
>
> I don't fully understand this. Oddly the same seems to happen locally
> on my x86_64 box. So maybe the configure macros we have been using
> have
> always been bad/broken?
No, this is "normal". It first tries without the -l library (which is
the failing case) and then with the -l library (which succeeds).
What goes wrong is that this debian old stable arm setup has libzstd
containing a ZSTD_compressStream2 symbol...
40: d349 264 FUNCGLOBAL DEFAULT 11 ZSTD_compressStream2
But the zstd.h header doesn't expose it...
/***
*
* ADVANCED AND EXPERIMENTAL FUNCTIONS
***
*
* The definitions in the following section are considered experimental.
* They are provided for advanced scenarios.
* They should never be used with a dynamic library, as prototypes may change in
the future.
* Use them only in association with static linking.
* *
**/
#if defined(ZSTD_STATIC_LINKING_ONLY) &&
!defined(ZSTD_H_ZSTD_STATIC_LINKING_ONLY)
...
grmbl.
This is somewhat unfortunate. We need a smarter configure check for this...
Cheers,
Mark
[Bug debuginfod/29926] New: debuginfod using deprecated curl (since 7.55.0) curl API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Bug ID: 29926 Summary: debuginfod using deprecated curl (since 7.55.0) curl API, fails to build with 7.87.0 Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: andrew at ishiboo dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- The debuginfod build fails because it is using deprecated curl APIs that were marked deprecated in 7.55 and hard-deprecated in 7.87, triggering -Werror=deprecated-declarations errors: ../../debuginfod/debuginfod-client.c: In function 'debuginfod_query_server': ../../debuginfod/debuginfod-client.c:895:15: error: 'CURLINFO_SIZE_DOWNLOAD' is deprecated: since 7.55.0. Use CURLINFO_SIZE_DOWNLOAD_T [-Werror=deprecated-declarations] 895 | curl_res = curl_easy_getinfo(target_handle, | ^~~~ In file included from ../../debuginfod/debuginfod-client.c:86: /opt/bbinfra/include/curl/curl.h:2836:3: note: declared here 2836 | CURLINFO_SIZE_DOWNLOAD | ^~ ../../debuginfod/debuginfod-client.c:913:15: error: 'CURLINFO_CONTENT_LENGTH_DOWNLOAD' is deprecated: since 7.55.0. Use CURLINFO_CONTENT_LENGTH_DOWNLOAD_T [-Werror=deprecated-declarations] 913 | curl_res = curl_easy_getinfo(target_handle, | ^~~~ In file included from ../../debuginfod/debuginfod-client.c:86: /opt/bbinfra/include/curl/curl.h:2853:3: note: declared here 2853 | CURLINFO_CONTENT_LENGTH_DOWNLOAD | ^~~~ ../../debuginfod/debuginfod-client.c: In function 'debuginfod_query_server': ../../debuginfod/debuginfod-client.c:895:15: error: 'CURLINFO_SIZE_DOWNLOAD' is deprecated: since 7.55.0. Use CURLINFO_SIZE_DOWNLOAD_T [-Werror=deprecated-declarations] 895 | curl_res = curl_easy_getinfo(target_handle, | ^~~~ In file included from ../../debuginfod/debuginfod-client.c:86: /opt/bbinfra/include/curl/curl.h:2836:3: note: declared here 2836 | CURLINFO_SIZE_DOWNLOAD | ^~ ../../debuginfod/debuginfod-client.c:913:15: error: 'CURLINFO_CONTENT_LENGTH_DOWNLOAD' is deprecated: since 7.55.0. Use CURLINFO_CONTENT_LENGTH_DOWNLOAD_T [-Werror=deprecated-declarations] 913 | curl_res = curl_easy_getinfo(target_handle, | ^~~~ In file included from ../../debuginfod/debuginfod-client.c:86: /opt/bbinfra/include/curl/curl.h:2853:3: note: declared here 2853 | CURLINFO_CONTENT_LENGTH_DOWNLOAD | ^~~~ cc1: all warnings being treated as errors This is due to the code having an `#ifdef` fallback on the old identifiers that must be removed to compile with 7.87. -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] libdwfl: Don't undef _
A couple of files undefined _, which is defined in lib/eu-config.h as gettext helper macro. This seems unnecessary and arbitrary. Signed-off-by: Mark Wielaard --- libdwfl/ChangeLog| 7 +++ libdwfl/core-file.c | 1 - libdwfl/dwfl_segment_report_module.c | 1 - libdwfl/elf-from-memory.c| 1 - libdwfl/open.c | 1 - 5 files changed, 7 insertions(+), 4 deletions(-) diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog index 1b465e48..9cd2f03c 100644 --- a/libdwfl/ChangeLog +++ b/libdwfl/ChangeLog @@ -1,3 +1,10 @@ +2022-12-21 Mark Wielaard + + * core-file.c: Don't undef _. + * dwfl_segment_report_module.c: Likewise. + * elf-from-memory.c: Likewise. + * open.c: Likewise. + 2022-12-20 Mark Wielaard * Makefile.am (AM_CPPFLAGS): debuginfod.h is in builddir. diff --git a/libdwfl/core-file.c b/libdwfl/core-file.c index 1ddf0f18..87c940cb 100644 --- a/libdwfl/core-file.c +++ b/libdwfl/core-file.c @@ -29,7 +29,6 @@ #include #include "libelfP.h" /* For NOTE_ALIGN. */ -#undef _ #include "libdwflP.h" #include diff --git a/libdwfl/dwfl_segment_report_module.c b/libdwfl/dwfl_segment_report_module.c index 41285103..3ef62a7d 100644 --- a/libdwfl/dwfl_segment_report_module.c +++ b/libdwfl/dwfl_segment_report_module.c @@ -29,7 +29,6 @@ #include #include "libelfP.h" /* For NOTE_ALIGN4 and NOTE_ALIGN8. */ -#undef _ #include "libdwflP.h" #include "common.h" diff --git a/libdwfl/elf-from-memory.c b/libdwfl/elf-from-memory.c index f7fb3ab7..e9b330fd 100644 --- a/libdwfl/elf-from-memory.c +++ b/libdwfl/elf-from-memory.c @@ -28,7 +28,6 @@ #include #include "libelfP.h" -#undef _ #include "libdwflP.h" diff --git a/libdwfl/open.c b/libdwfl/open.c index 32bd7ff8..fcb7f8ea 100644 --- a/libdwfl/open.c +++ b/libdwfl/open.c @@ -32,7 +32,6 @@ #endif #include "libelfP.h" -#undef _ #include "libdwflP.h" #if !USE_BZLIB -- 2.30.2
[Bug debuginfod/29926] debuginfod using deprecated curl (since 7.55.0) curl API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 --- Comment #1 from Andrew Paprocki --- Created attachment 14535 --> https://sourceware.org/bugzilla/attachment.cgi?id=14535&action=edit Fix selection of non-deprecated Curl API The `CURLINFO_SIZE_DOWNLOAD_T` and `CURLINFO_CONTENT_LENGTH_DOWNLOAD_T` identifiers are `enum`s, not pre-processor definitions, so the current `#ifdef` logic is not selecting the newer API. This results in the older identifiers being used and they now generate errors when compiled against Curl 7.87, which has silently deprecated them, causing GCC to emit `-Werror=deprecated-declarations`. Instead, the newer identifiers were added in Curl 7.55, so explicitly check for `CURL_AT_LEAST_VERSION(7, 55, 0)` instead of the current logic. This eliminates the error when compiling against Curl 7.87. Ref: https://github.com/curl/curl/pull/1511 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29926] debuginfod using deprecated curl (since 7.55.0) API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Andrew Paprocki changed: What|Removed |Added Summary|debuginfod using deprecated |debuginfod using deprecated |curl (since 7.55.0) curl|curl (since 7.55.0) API, |API, fails to build with|fails to build with 7.87.0 |7.87.0 | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29926] debuginfod using deprecated curl (since 7.55.0) API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||fche at redhat dot com --- Comment #2 from Frank Ch. Eigler --- Thanks, merged! -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH 08/25] Use configure to detect HAVE_DECL_MMAP and use it for system doesn't provide sys/mman.h
Hi, On Wed, 2022-12-21 at 00:30 +0800, 罗勇刚(Yonggang Luo) via Elfutils-devel wrote: > On Tue, Dec 20, 2022 at 10:04 PM Mark Wielaard > wrot > > I have to think what it means for a system that doesn't have mmap > > since > > the mmap extensions are part of the public interface. And various > > parts > > of the libraries depend on knowledge that they can read/write > > directly > > from mmapped parts. Does it really make sense to try to support a > > platform without mmap? > > Windows have mmap, just didn't have the direct posix mman API So how does the API look like? Is there a posix mmap emulation available? Thanks, Mark
☠ Buildbot (GNU Toolchain): elfutils - failed compile (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/117 Build state: failed compile (failure) Revision: d2bf497b12fbd49b4996ccf0744303ffd67735b1 Worker: centos-x86_64 Build Reason: (unknown) Blamelist: Andrew Paprocki Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/5/logs/property_changes - 6: make ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/6/logs/stdio A restored build has been detected on builder elfutils-fedora-ppc64le while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/55/builds/115 Build state: build successful Revision: d2bf497b12fbd49b4996ccf0744303ffd67735b1 Worker: fedora-ppc64le Build Reason: (unknown) Blamelist: Andrew Paprocki , Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/6/logs/warnings__3_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/55/builds/115/steps/18/logs/stdio A new failure has been detected on builder elfutils-fedora-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/59/builds/122 Build state: failed test (failure) Revision: d2bf497b12fbd49b4996ccf0744303ffd67735b1 Worker: bb3 Build Reason: (unknown) Blamelist: Andrew Paprocki Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git c
Re: ☠ Buildbot (GNU Toolchain): elfutils - failed compile (failure) (master)
On Wed, 2022-12-21 at 17: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/117
>
> Build state: failed compile (failure)
> Revision: d2bf497b12fbd49b4996ccf0744303ffd67735b1
> Worker: centos-x86_64
> Build Reason: (unknown)
> Blamelist: Andrew Paprocki
>
> Steps:
> [...]
> - 6: make ( failure )
> Logs:
> - stdio:
> https://builder.sourceware.org/buildbot/#builders/39/builds/117/steps/6/logs/stdio
Oops, we need a version check to see if CURL_AT_LEAST_VERSION is
available... doh.
Fixed with the attached patch.
Cheers,
Mark
From 304741e11018c29e7ff17751e05dcc5c786a3fd9 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Wed, 21 Dec 2022 18:21:08 +0100
Subject: [PATCH] debuginfod: Define CURL_AT_LEAST_VERSION if necessary
Older curl.h don't define CURL_AT_LEAST_VERSION, so define it
ourselves because it is nicer than doing hex encoded version
comparisons.
Signed-off-by: Mark Wielaard
---
debuginfod/ChangeLog | 4
debuginfod/debuginfod-client.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index 2c65d862..2ddb7ca0 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,7 @@
+2022-12-21 Mark Wielaard
+
+ * debuginfod-client.c: Define CURL_AT_LEAST_VERSION.
+
2022-12-21 Andrew Paprocki
* debuginfod-client.c: Make compilable against newer curl. PR29926
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 692aecce..a16165bd 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -105,6 +105,13 @@ void debuginfod_end (debuginfod_client *c) { }
#include
#endif
+/* Older curl.h don't define CURL_AT_LEAST_VERSION. */
+#ifndef CURL_AT_LEAST_VERSION
+ #define CURL_VERSION_BITS(x,y,z) ((x)<<16|(y)<<8|(z))
+ #define CURL_AT_LEAST_VERSION(x,y,z) \
+(LIBCURL_VERSION_NUM >= CURL_VERSION_BITS(x, y, z))
+#endif
+
#include
static pthread_once_t init_control = PTHREAD_ONCE_INIT;
--
2.18.4
Re: [PATCH v2 05/16] libcpu: Remove the need of NMNES by using enum
Hi,
On Sun, 2022-12-18 at 00:52 +0800, Yonggang Luo via Elfutils-devel
wrote:
> Signed-off-by: Yonggang Luo
> ---
> libcpu/Makefile.am | 2 +-
> libcpu/i386_disasm.c | 14 +-
> libcpu/i386_mne.h| 36
> libcpu/i386_parse.y | 9 +++--
> 4 files changed, 41 insertions(+), 20 deletions(-)
> create mode 100644 libcpu/i386_mne.h
>
> diff --git a/libcpu/Makefile.am b/libcpu/Makefile.am
> index 57d0a164..259ed838 100644
> --- a/libcpu/Makefile.am
> +++ b/libcpu/Makefile.am
> @@ -92,7 +92,7 @@ libeu = ../lib/libeu.a
> i386_lex_CFLAGS = -Wno-unused-label -Wno-unused-function -Wno-sign-
> compare \
> -Wno-implicit-fallthrough
> i386_parse.o: i386_parse.c i386.mnemonics
> -i386_parse_CFLAGS = -DNMNES="`wc -l < i386.mnemonics`"
> +i386_parse_CFLAGS =
> i386_lex.o: i386_parse.h
> i386_gendis_LDADD = $(libeu) -lm $(obstack_LIBS)
The new i386_mne.h file should be added to noinst_HEADERS (or it won't
be included in a make dist, so make distcheck fails).
> diff --git a/libcpu/i386_disasm.c b/libcpu/i386_disasm.c
> index 599d1654..c34f03d6 100644
> --- a/libcpu/i386_disasm.c
> +++ b/libcpu/i386_disasm.c
> @@ -46,10 +46,7 @@
> #define MACHINE_ENCODING LITTLE_ENDIAN
> #include "memory-access.h"
>
> -
> -#ifndef MNEFILE
> -# define MNEFILE "i386.mnemonics"
> -#endif
> +#include "i386_mne.h"
>
> #define MNESTRFIELD(line) MNESTRFIELD1 (line)
> #define MNESTRFIELD1(line) str##line
> @@ -71,15 +68,6 @@ static const union mnestr_t
> }
>};
>
> -/* The index can be stored in the instrtab. */
> -enum
> - {
> -#define MNE(name) MNE_##name,
> -#include MNEFILE
> -#undef MNE
> -MNE_INVALID
> - };
> -
> static const unsigned short int mneidx[] =
>{
> #define MNE(name) \
OK.
> diff --git a/libcpu/i386_mne.h b/libcpu/i386_mne.h
> new file mode 100644
> index ..41dacf61
> --- /dev/null
> +++ b/libcpu/i386_mne.h
> @@ -0,0 +1,36 @@
> +/* Compute hash value for given string according to ELF standard.
> + Copyright (C) 1995-2015 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
> + The GNU C Library is free software; you can redistribute it
> and/or
> + modify it under the terms of the GNU Lesser General Public
> + License as published by the Free Software Foundation; either
> + version 2.1 of the License, or (at your option) any later
> version.
> +
> + The GNU C Library is distributed in the hope that it will be
> useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + Lesser General Public License for more details.
> +
> + You should have received a copy of the GNU Lesser General Public
> + License along with the GNU C Library; if not, see
> +
Re: [PATCH v2 06/16] libcpu: Use __asm instead asm that can be recognized by both clang-cl and gcc
On Sun, 2022-12-18 at 00:52 +0800, Yonggang Luo via Elfutils-devel
wrote:
> This block of code can not be removed. As it's contains a goto label
> enomem that been used elsewhere
aha, that certainly explains why gcc gets confused about whether those
variables are used. It is slightly ugly code :{
But added a ChangeLog entry and pushed as attached.
Thanks,
Mark
From 1984819d6ee2dc56583d3f11b9f6e3b2f491f62e Mon Sep 17 00:00:00 2001
From: Yonggang Luo
Date: Sun, 18 Dec 2022 00:52:03 +0800
Subject: [PATCH] libcpu: Use __asm instead of asm to mark variables as used
This block of code can not be removed. As it's contains a goto label
enomem that been used elsewhere.
Signed-off-by: Yonggang Luo
---
libcpu/ChangeLog | 4
libcpu/i386_disasm.c | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libcpu/ChangeLog b/libcpu/ChangeLog
index bd517b94..6d4b717a 100644
--- a/libcpu/ChangeLog
+++ b/libcpu/ChangeLog
@@ -1,3 +1,7 @@
+2022-12-18 Yonggang Luo
+
+ * i386_disasm.c (i386_disasm): Use __asm instead of asm.
+
2022-12-20 Mark Wielaard
* bpf_disasm.c: Include common.h and libeblP.h.
diff --git a/libcpu/i386_disasm.c b/libcpu/i386_disasm.c
index c42f8d1c..09946273 100644
--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -480,8 +480,8 @@ i386_disasm (Ebl *ebl __attribute__((unused)),
/* gcc is not clever enough to see the following variables
are not used uninitialized. */
- asm (""
- : "=mr" (opoff), "=mr" (correct_prefix), "=mr" (codep),
+ __asm (""
+ : "=mr" (opoff), "=mr" (correct_prefix), "=mr" (codep),
"=mr" (next_curr), "=mr" (len));
}
--
2.18.4
Re: [PATCH v2 12/16] libasm/debuginfod: fchmod doesn't present on win32
Hi,
On Sun, 2022-12-18 at 00:52 +0800, Yonggang Luo via Elfutils-devel
wrote:
> index 8873fcc8..7a67a440 100644
> --- a/debuginfod/debuginfod-client.c
> +++ b/debuginfod/debuginfod-client.c
> @@ -1708,9 +1708,11 @@ debuginfod_query_server (debuginfod_client *c,
>tvs[0].tv_usec = tvs[1].tv_usec = 0;
>(void) futimes (fd, tvs); /* best effort */
>
> +#if !defined(_WIN32)
>/* PR27571: make cache files casually unwriteable; dirs are
> already 0700 */
>(void) fchmod(fd, 0400);
> -
> +#endif
> +
>/* rename tmp->real */
>rc = rename (target_cache_tmppath, target_cache_path);
>if (rc < 0)
> diff --git a/libasm/asm_end.c b/libasm/asm_end.c
> index c06d2366..54540bc1 100644
> --- a/libasm/asm_end.c
> +++ b/libasm/asm_end.c
> @@ -512,12 +512,14 @@ asm_end (AsmCtx_t *ctx)
>if (result != 0)
> return result;
>
> +#if !defined(_WIN32)
>/* Make the new file globally readable and user/group-
> writable. */
>if (fchmod (ctx->fd, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP |
> S_IROTH) != 0)
> {
>__libasm_seterrno (ASM_E_CANNOT_CHMOD);
>return -1;
> }
> +#endif
I don't like the __WIN32 define checks. Is fchmod really not
available?? It seems it is a standard Posix function. Can we have a
configure check for it then?
Thanks,
Mark
☠ Buildbot (GNU Toolchain): elfutils - failed test (failure) (master)
A new failure has been detected on builder elfutils-debian-i386 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/17/builds/116 Build state: failed test (failure) Revision: 304741e11018c29e7ff17751e05dcc5c786a3fd9 Worker: debian-i386-2 Build Reason: (unknown) Blamelist: Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/6/logs/warnings__3_ - 7: make check ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/116/steps/18/logs/stdio 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/118 Build state: build successful Revision: 304741e11018c29e7ff17751e05dcc5c786a3fd9 Worker: centos-x86_64 Build Reason: (unknown) Blamelist: Andrew Paprocki , Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/6/logs/stdio - warnings (2): https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/6/logs/warnings__2_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/39/builds/118/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.so
Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
On 12/21/22 16:21, Mark Wielaard wrote:
> Hi,
>
> On Wed, 2022-12-21 at 15:42 +0100, Mark Wielaard wrote:
>>
>> Unfortunately buildbot itself doesn't show the config.log.
>> Trying to get that...
>>
>> configure:6961: checking for library containing ZSTD_compressStream2
>> configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
>> -fsanitize=undefined
>> -fno-sanitize-recover -fsanitize=address -fno-sanitize-
>> recover conftest.c -llz
>> ma -lbz2 >&5
>> /usr/bin/ld: /tmp/ccKZnuYA.o: in function `main':
>> /var/lib/buildbot/workers/wildebeest/elfutils-try-debian-
>> armhf/build/conftest.c:
>> 30: undefined reference to `ZSTD_compressStream2'
>> collect2: error: ld returned 1 exit status
>> configure:6992: $? = 1
>> configure: failed program was:
>>> /* confdefs.h */
>>> #define PACKAGE_NAME "elfutils"
>>> #define PACKAGE_TARNAME "elfutils"
>>> #define PACKAGE_VERSION "0.188"
>>> #define PACKAGE_STRING "elfutils 0.188"
>>> #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla";
>>> #define PACKAGE_URL "http://elfutils.org/";
>>> #define PACKAGE "elfutils"
>>> #define VERSION "0.188"
>>> #define DEFAULT_AR_DETERMINISTIC false
>>> #define HAVE_VISIBILITY 1
>>> #define HAVE_STDATOMIC_H 1
>>> #define _FILE_OFFSET_BITS 64
>>> #define CHECK_UNDEFINED 1
>>> #define USE_ZLIB 1
>>> #define USE_BZLIB 1
>>> #define USE_LZMA 1
>>> /* end confdefs.h. */
>>>
>>> /* Override any GCC internal prototype to avoid an error.
>>>Use char because int might match the return type of a GCC
>>>builtin and then its argument prototype would still apply. */
>>> #ifdef __cplusplus
>>> extern "C"
>>> #endif
>>> char ZSTD_compressStream2 ();
>>> int
>>> main ()
>>> {
>>> return ZSTD_compressStream2 ();
>>> ;
>>> return 0;
>>> }
>>
>> configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
>> -fsanitize=undefined
>> -fno-sanitize-recover -fsanitize=address -fno-sanitize-
>> recover conftest.c -lzs
>> td -llzma -lbz2 >&5
>> configure:6992: $? = 0
>> configure:7009: result: -lzstd
>>
>> ehe? So it fails and then succeeds anyway?
>>
>> Strangely the same happens for the other compression library
>> checks...
>> lzma_auto_decoder and BZ2_bzdopen
>>
>> I don't fully understand this. Oddly the same seems to happen locally
>> on my x86_64 box. So maybe the configure macros we have been using
>> have
>> always been bad/broken?
>
Hi.
Good!
> No, this is "normal". It first tries without the -l library (which is
> the failing case) and then with the -l library (which succeeds).
Ah, makes sense.
>
> What goes wrong is that this debian old stable arm setup has libzstd
> containing a ZSTD_compressStream2 symbol...
>
> 40: d349 264 FUNCGLOBAL DEFAULT 11 ZSTD_compressStream2
>
> But the zstd.h header doesn't expose it...
Yeah, that's their way of how to move an API from "staging" into a stable state.
It was changed in:
https://github.com/facebook/zstd/commit/d7d89513d6a21
and so it's present in zstd since 1.4.0. Can we somehow specify library version
in configure.ac?
Thanks,
Martin
>
> /***
> *
> * ADVANCED AND EXPERIMENTAL FUNCTIONS
>
> ***
> *
> * The definitions in the following section are considered experimental.
> * They are provided for advanced scenarios.
> * They should never be used with a dynamic library, as prototypes may change
> in
> the future.
> * Use them only in association with static linking.
> *
> *
> **/
>
> #if defined(ZSTD_STATIC_LINKING_ONLY) &&
> !defined(ZSTD_H_ZSTD_STATIC_LINKING_ONLY)
>
> ...
>
> grmbl.
>
> This is somewhat unfortunate. We need a smarter configure check for this...
>
> Cheers,
>
> Mark
☺ Buildbot (GNU Toolchain): elfutils - build successful (master)
A restored build has been detected on builder elfutils-debian-i386 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/17/builds/117 Build state: build successful Revision: 1984819d6ee2dc56583d3f11b9f6e3b2f491f62e Worker: debian-i386-2 Build Reason: (unknown) Blamelist: Mark Wielaard , Yonggang Luo Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/6/logs/warnings__3_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/17/builds/117/steps/18/logs/stdio
Re: [PATCH v2 15/16] libelf: F_GETFD may not predefined with msvc/mingw, guard the usage of it
Hi,
On Sun, Dec 18, 2022 at 12:52:12AM +0800, Yonggang Luo via Elfutils-devel wrote:
> Signed-off-by: Yonggang Luo
> ---
> libelf/elf_begin.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libelf/elf_begin.c b/libelf/elf_begin.c
> index 6d31882e..3d324694 100644
> --- a/libelf/elf_begin.c
> +++ b/libelf/elf_begin.c
> @@ -1163,12 +1163,19 @@ elf_begin (int fildes, Elf_Cmd cmd, Elf *ref)
>if (ref != NULL)
> /* Make sure the descriptor is not suddenly going away. */
> rwlock_rdlock (ref->lock);
> +#if defined(F_GETFD)
>else if (unlikely (fcntl (fildes, F_GETFD) == -1 && errno == EBADF))
> {
>/* We cannot do anything productive without a file descriptor. */
>__libelf_seterrno (ELF_E_INVALID_FILE);
>return NULL;
> }
> +#else
> + else if (fildes < 0)
> +{
> + return NULL;
> +}
> +#endif
That new return NULL is missing a __libelf_seterrno.
Cheers,
Mark
Re: [PATCH] lib: Remove -ffunction-sections for xmalloc
On Tue, Dec 20, 2022 at 11:22:23PM +0100, Mark Wielaard wrote: > The build used -ffunction-sections just for one file. > > +2022-12-20 Mark Wielaard > + > + * Makefile.am (xmalloc_CFLAGS): Remove. Pushed.
Re: [PATCH v2 16/16] lib: Use HAVE_LIBINTL_H to guard #include
Hi,
On Sun, Dec 18, 2022 at 12:52:13AM +0800, Yonggang Luo via Elfutils-devel wrote:
> MSVC doesn't have libintl.h, so use macro to guard it.
>
> Signed-off-by: Yonggang Luo
> ---
> configure.ac| 2 ++
> lib/eu-config.h | 7 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index b84623fe..aea12be3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -441,6 +441,8 @@ AC_CHECK_FUNCS([process_vm_readv mremap])
> AS_IF([test "x$ac_cv_func_mremap" = "xno"],
>[AC_MSG_WARN([elf_update needs mremap to support ELF_C_RDWR_MMAP])])
>
> +AC_CHECK_HEADERS([libintl.h])
> +
> AC_CHECK_HEADERS([error.h])
> AC_CHECK_HEADERS([err.h])
We already use AM_GNU_GETTEXT. I think that would detect whether there
is gettext/libintl.h support already. Which defines ENABLE_NLS.
> diff --git a/lib/eu-config.h b/lib/eu-config.h
> index 78a5c4fe..72b7793e 100644
> --- a/lib/eu-config.h
> +++ b/lib/eu-config.h
> @@ -52,10 +52,17 @@
> # define rwlock_unlock(lock) ((void) (lock))
> #endif /* USE_LOCKS */
>
> +#if defined(HAVE_LIBINTL_H)
> #include
> +#endif
> +
> /* gettext helper macros. */
> #define N_(Str) Str
> +#if defined(HAVE_LIBINTL_H)
> #define _(Str) dgettext ("elfutils", Str)
> +#else
> +#define _(Str) N_(Str)
> +#endif
So I think the guard here is should be #if ENABLE_NLS
Also just define _(Str) Str directly instead of going through N_(Str).
Cheers,
Mark
Re: [PATCHv2] support ZSTD compression algorithm
Hi Martin, On Wed, Dec 21, 2022 at 12:09:21PM +0100, Martin Liška wrote: > > Or you return a special value from the function (assuming all callers > > check for an error here). And/Or if the program needs a cleanup you'll > > goto cleanup (as is done in process_file). > > I think it's fine as we return UNSET in that case and the caller goes directly > to cleanup (or abort is called for the second call site): > > enum ch_type schtype = get_section_chtype (scn, shdr, sname, ndx); > if (schtype == UNSET) > goto cleanup; O, that is good. Is the abort () at the second call site because that cannot happen? Or should that also goto cleanup? Cheers, Mark
Re: [PATCH v4] Add support for Synopsys ARCv2 processors
Hi Shahab, On Wed, Dec 21, 2022 at 12:27:05PM +0100, Shahab Vahedi via Elfutils-devel wrote: > There is no regression in tests for an x86_64 build, while the new > hello_arc_hs4.ko is added as well. This is the only meaningful > test that I could add at the moment, given the features supported > by this port. > > $ cat tests/test-suite.log > == > elfutils 0.188: tests/test-suite.log > == > > # TOTAL: 236 > # PASS: 235 > # SKIP: 1 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > SKIP: run-lfs-symbols.sh > > > LFS testing is irrelevant on this system > SKIP run-lfs-symbols.sh (exit status: 77) > > $ cat tests/run-strip-reloc.sh.log > runtest hello_i386.ko > runtest hello_x86_64.ko > runtest hello_ppc64.ko > runtest hello_s390.ko > runtest hello_aarch64.ko > runtest hello_m68k.ko > runtest hello_riscv64.ko > runtest hello_csky.ko > runtest hello_arc_hs4.ko<-- [ new ARC HS4 test ] > runtest /home/shahab/pahole_pkg/elfutils-git/bld_arc/src/strip > runtest /home/shahab/pahole_pkg/elfutils-git/bld_arc/src/strip.o > runtest strip-uncompressed.o > runtest strip-compressed.o > runtest testfile-debug-rel-ppc64.o > runtest testfile-debug-rel-ppc64-z.o > runtest testfile-debug-rel-ppc64-g.o > PASS run-strip-reloc.sh (exit status: 0) > > Signed-off-by: Shahab Vahedi > --- > Changelog: > v4: > - Add EM_ARCV2 to valid_e_machine[] in src/elflint.c. > - Add a link to ARCv3 elf document in arc_init.c. > - Update ChangeLogs. Very nice. Pushed. Thanks, Mark
Re: [PATCH] libdwfl: Don't undef _
On Wed, Dec 21, 2022 at 04:43:05PM +0100, Mark Wielaard wrote: > A couple of files undefined _, which is defined in lib/eu-config.h as > gettext helper macro. This seems unnecessary and arbitrary. Pushed.
Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
Hi Martin, On Wed, Dec 21, 2022 at 07:29:19PM +0100, Martin Liška wrote: > > What goes wrong is that this debian old stable arm setup has libzstd > > containing a ZSTD_compressStream2 symbol... > > > > 40: d349 264 FUNCGLOBAL DEFAULT 11 ZSTD_compressStream2 > > > > But the zstd.h header doesn't expose it... > > Yeah, that's their way of how to move an API from "staging" into a stable > state. > It was changed in: > https://github.com/facebook/zstd/commit/d7d89513d6a21 > > and so it's present in zstd since 1.4.0. Can we somehow specify library > version > in configure.ac? It isn't as nice, but since there seems to be a pkgconfig libzstd.pc you could use PKG_CHECK_MODULES. See for example how we check for libcurl. Cheers, Mark
Re: [PATCH 08/25] Use configure to detect HAVE_DECL_MMAP and use it for system doesn't provide sys/mman.h
On Thu, Dec 22, 2022 at 12:54 AM Mark Wielaard wrote: > > Hi, > > On Wed, 2022-12-21 at 00:30 +0800, 罗勇刚(Yonggang Luo) via Elfutils-devel > wrote: > > On Tue, Dec 20, 2022 at 10:04 PM Mark Wielaard > > wrot > > > I have to think what it means for a system that doesn't have mmap > > > since > > > the mmap extensions are part of the public interface. And various > > > parts > > > of the libraries depend on knowledge that they can read/write > > > directly > > > from mmapped parts. Does it really make sense to try to support a > > > platform without mmap? > > > > Windows have mmap, just didn't have the direct posix mman API > > So how does the API look like? Is there a posix mmap emulation > available? Cygwin did that, other than cygwin, for mingw/msvc, there is https://github.com/klauspost/mman-win32/blob/master/mman.h > > Thanks, > > Mark -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
