Bug 32527 - elfutils build warnings when building GCC -O3
Summary: elfutils build warnings when building GCC -O3
Status: RESOLVED FIXED
Alias: None
Product: elfutils
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-06 17:53 UTC by Phi
Modified: 2025-01-11 13:04 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
attachment-1205926-0.html (399 bytes, text/html)
2025-01-07 12:38 UTC, Phi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phi 2025-01-06 17:53:00 UTC
Hi

I used the component 'General' because the component 'libcpu' don't exist in the selection list.

When building on ubuntu 24.04 GCC (and g++) 14.2.0 with options -m64 -O3 -g1 on x86_64 and s390, we got warnings, yet make check show no errors, this is why I marked this as 'enhancement'

The warnings occurs when building libcpu/i386_lex.o from i386_lex.l.
-------------------------
In function ‘i386__init_buffer’,
    inlined from ‘i386_restart’ at i386_lex.c:1699:2:
i386_lex.c:1815:25: warning: potential null pointer dereference [-Wnull-dereference]
 1815 |         b->yy_bs_column = 0;
      |         ~~~~~~~~~~~~~~~~^~~
i386_lex.c:1814:25: warning: potential null pointer dereference [-Wnull-dereference]
...
-------------------------

Indeed this is not critical at all, but I try to build with no warnings.

The warning is due to the flex skeleton for lexer that use a pointer from malloc() that could be NULL, even though this never happen except may be on stressed systems, it is still possible, the punishment would be a core dump though. This occurs only with gcc -O3, -O2 don't show this, clang never show it.

I think gcc -O3 is right though, it do more inlining and discover the potentially faulty unchecked malloc (we use the std def yymalloc == malloc)

Since we have little chance to get the lexer skeleton fixed from flex team, a possible workaround is to add the option  -Wno-null-dereference in the file
elfutils/libcpu/Makefile.am like this

i386_lex_CFLAGS = -Wno-unused-label -Wno-unused-function -Wno-sign-compare \
		  -Wno-implicit-fallthrough -Wno-null-dereference

By doing so, the warning disapear, we don't jeopardise anything, and it is cleaner for the one who wants to build the perf path with no warnings.

Cheers,
Phi
Comment 1 Sam James 2025-01-06 19:04:19 UTC
(In reply to Phi from comment #0)
> Since we have little chance to get the lexer skeleton fixed from flex team,
> a possible workaround is to add the option  -Wno-null-dereference in the file
> elfutils/libcpu/Makefile.am like this
> 

Please file a bug with flex first if it isn't fixed on master (a lot of changes are in flex master compared to the last release).
Comment 2 Phi 2025-01-07 10:32:27 UTC
Actually flex is not at fault, I overlooked the skeleton, each yyalloc() (i.e malloc() ) are protected by a if(!b)YY_FATAL_ERROR()...

The bug is more in GCC -O3 inhability to track that b is never NULL when calling yy_init_buffer(b,...), note that yy_init_buffer() is static and then inlined in local callers when b is guaranted never NULL.

Clang don't have that.

Sorry for the false claim on flex.

The problem on GCC is already open on GCC 13, still going on 14, so probably will take a long time to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856

I think adding one more -Wno-... in the i386_lex_CFLAGS in libcp/Makefile.am is a good way to expedite this false positive warnings fix.

I thing i386_lex_CFLAGS was put in place just for this kind of hack, and this just suppress warning in the lexer, it doesn't jeopardize anything in elfutils.


Cheers,
Phi
Comment 3 Phi 2025-01-07 12:38:36 UTC
Created attachment 15872 [details]
attachment-1205926-0.html

Hi Sam,

Sorry I didn't saw your email, I did reply directly in the bugzilla ticket,
the problem is not flex as I first thought but more GCC -O3, I let you read
what I wrote there.

I think the propose fix is harmless.

I didn't submitted a patch because I am not sure how to fill the paper
work, and I do very little work on elfutils. If you think posting a patch
is better appropriate I can review the process.

Cheers,
Phi
Comment 4 Phi 2025-01-11 13:04:39 UTC
Fixed in main branch
commit 977c4dba220db572fe5ff43b6eb8b81673be0ef7
Author: Philippe Benard <phi.debian@gmail.com>
Date:   Thu Jan 9 14:59:00 2025 +0100