[Bug general/24068] New: readelf.c:10152:15: error: ‘%*llx’ directive output between 4 and 2147483647 bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=] with -m32
https://sourceware.org/bugzilla/show_bug.cgi?id=24068
Bug ID: 24068
Summary: readelf.c:10152:15: error: ‘%*llx’ directive output
between 4 and 2147483647 bytes may cause result to
exceed ‘INT_MAX’ [-Werror=format-overflow=] with -m32
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: marxin.liska at gmail dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Using latest GCC and -m32 (on x86_64-linux-gnu), one can see:
$ gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/local/share/locale"'
-DDEBUGPRED=0 -DSRCDIR=\"/home/marxin/Programming/elfutils/src\"
-DOBJDIR=\"/home/marxin/Programming/elfutils/src\" -I. -I.. -I. -I. -I../lib
-I.. -I./../libelf -I./../libebl -I./../libdw -I./../libdwelf -I./../libdwfl
-I./../libasm -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition
-Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond
-Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused -Wextra
-D_FORTIFY_SOURCE=2 -g -O2 -MT readelf.o -MD -MP -MF .deps/readelf.Tpo -c -o
readelf.o readelf.c -m32
readelf.c: In function ‘print_debug_str_section’:
readelf.c:10152:15: error: ‘%*llx’ directive output between 4 and 2147483647
bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=]
10152 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
readelf.c:10152:18: note: format string is defined here
10152 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
readelf.c:10152:15: note: directive argument in the range [0,
18446744073709551614]
10152 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
cc1: all warnings being treated as errors
Can you please check that?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/24068] readelf.c:10152:15: error: ‘%*llx’ directive output between 4 and 2147483647 bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=] with -m32
https://sourceware.org/bugzilla/show_bug.cgi?id=24068
Martin Liška changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=88835
--- Comment #2 from Martin Liška ---
(In reply to Mark Wielaard from comment #1)
> This is weird. I cannot replicate with a standard build and gcc (GCC) 9.0.0
> 20190112 (experimental).
>
> Aha, with -m32. hmmm. Odd.
>
> So the issue seems to be that GCC doesn't realize digits is capped between 4
> and 16. We could help with with something like:
Probably.
>
> diff --git a/src/readelf.c b/src/readelf.c
> index 3a73710ff..83b700eee 100644
> --- a/src/readelf.c
> +++ b/src/readelf.c
> @@ -10128,7 +10128,7 @@ print_debug_str_section (Dwfl_Module *dwflmod
> __attribute__ ((unused)),
>++digits;
>tmp >>= 4;
> }
> - digits = MAX (4, digits);
> + digits = MIN (16, MAX (4, digits));
>
>printf (gettext ("\nDWARF section [%2zu] '%s' at offset %#" PRIx64 ":\n"
>" %*s String\n"),
>
> I that the correct fix though? Or is something else going on?
I can confirm it fixes that.
> I don't understand why this is -m32 specific.
Me neither, so that I created GCC PR for that.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/25448] New: Extend debuginfod metrics
https://sourceware.org/bugzilla/show_bug.cgi?id=25448 Bug ID: 25448 Summary: Extend debuginfod metrics Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- I would like to see more statistics about HTTP requests like: - total_bytes transferred for each request type (debuginfo, executable, source) - # of requests for each request type -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] New: Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 Bug ID: 25509 Summary: Break a cyclic dependency by core packages Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- In openSUSE, we do face a problem with cyclic dependencies. Many core packages like gcc, glibc, elfutils or binutils depend on each other and create a cycle. The cycle should contain a reasonable amount of packages. When debuginfod was added to elfutils, we would have a huge bunch of dependencies caused by libhttpmicro and libsqlite. These have very many transitive dependencies. So that I was forced to split elfutils into 2 packages: elfutils and elfutils-debuginfod. The later contains all the new packages and is not part of the boostrap cycle. What's more problematic is that there are (and will be) tools that want to utilize libdebuginfod such as Binutils. As mentioned, the tool is in the bootstrap cycle and so that can't depend on elfutils-debuginfod. So the question is how to unbreak all these dependencies for future core packages? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #1 from Martin Liška --- I have basically 2 possible solutions: - elfutils will provide a stub client library (libdebuginfod-stub.so) which will then do dlopen for the real libdebuginfod.so during run-rime - one can do execv of debuginfod-find which is a standalone tool that can download a debuginfo -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #4 from Martin Liška --- (In reply to Mark Wielaard from comment #2) > (In reply to Martin Liška from comment #0) > > In openSUSE, we do face a problem with cyclic dependencies. Many core > > packages like gcc, glibc, elfutils or binutils depend on each other and > > create a cycle. The cycle should contain a reasonable amount of packages. > > > > When debuginfod was added to elfutils, we would have a huge bunch of > > dependencies caused by libhttpmicro and libsqlite. These have very many > > transitive dependencies. > > debuginfod the tool has dependencies on libhttpmicro, libsqlite, libdw and > debuginfod-client. > > debuginfod-client depends on libcurl (which pulls in a lot of the crypto > stuff for https support). > > libdw depends on debuginfod-client, but only indirectly through ldopen. > > It does make sense to put these in different (output/sub) packages. > Which is actually what the sample elfutils.spec file in config/ does. > > That doesn't "split" the inputs/dependencies of the source build though. > Which is what you seem most concerned with. > > > So that I was forced to split elfutils into 2 > > packages: elfutils and elfutils-debuginfod. The later contains all the new > > packages and is not part of the boostrap cycle. > > > > What's more problematic is that there are (and will be) tools that want to > > utilize libdebuginfod such as Binutils. As mentioned, the tool is in the > > bootstrap cycle and so that can't depend on elfutils-debuginfod. > > Do you have a pointer to the spec files you are using now? You can find the 2 spec files here: https://build.opensuse.org/package/show/Base:System/elfutils > > > So the question is how to unbreak all these dependencies for future core > > packages? > > The GNU Guix people also had some concerns about all the new dependencies > and also suggested splitting the package: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38803 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25227] "eu-nm --extern" skips first symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=25227 --- Comment #8 from Martin Liška --- Can the bug be closed? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25448] Extend debuginfod metrics
https://sourceware.org/bugzilla/show_bug.cgi?id=25448 --- Comment #2 from Martin Liška --- I like the suggested patch! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498
--- Comment #9 from Martin Liška ---
(In reply to Mark Wielaard from comment #8)
> I proposed a patch to use the new gcc 10 symver attribute to define symbol
> versioning:
>
> https://sourceware.org/pipermail/elfutils-devel/2020q2/002606.html
>
> This should help with using LTO since it makes the function symbols and
> versions visible to the compiler (before they were "hidden" inside asm
> statements).
There's an ongoing effort that will extend .symver GAS syntax:
https://sourceware.org/bugzilla/show_bug.cgi?id=25295
Later then, the GCC will utilize the new syntax.
>
> But I haven't tried to build all of elfutils with LTO enabled yet.
> How do you configure elfutils to enable LTO?
I would add a configure option --enable-lto that will append -flto to
{C,LD}FLAGS.
Thanks for working on that.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/24498] 0.176: isn't LTO ready
https://sourceware.org/bugzilla/show_bug.cgi?id=24498
--- Comment #11 from Martin Liška ---
(In reply to kloczek from comment #10)
> > I would add a configure option --enable-lto that will append -flto to
> > {C,LD}FLAGS.
>
> Please don't do that.
>
> LTO can be driven using only env variable.
>
> % CFLAGS="" LDFLAGS="" ./configure
Works for me.
>
> Please use KISS principle and do not implement something which can be
> already done other way *without* touching existing code.
>
> PS. Changing {C,LD}FLAGS is not only part of using LTO. You need to pass NM,
> RANLIB and AR env variables.
Not necessarily. Typical Linux systems, like openSUSE, utilize auto-loading
mechanism of LTO plugins:
$ strace -f -s512 nm foo.o 2>&1 | grep plugin
...
openat(AT_FDCWD, "/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0",
O_RDONLY|O_CLOEXEC) = 5
--
You are receiving this mail because:
You are on the CC list for the bug.
