[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #7 from Sergio Durigan Junior --- Ah, OK, I'll let you file the bug, then. Thanks.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #6 from Sergio Durigan Junior --- Thanks for the quick analysis. It seems that the following glibc commit dropped size hints from access when FORTIFY_SOURCE=3: https://sourceware.org/git/?p=glibc.git;a=commit;h=e938c02748402c50f60ba0eb983273e7b52937d1 I'll report a bug against glibc and mention this conversation. Thanks.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #2 from Sergio Durigan Junior --- Created attachment 57431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57431=edit Preprocessed source Sure thing. Here it is.
[Bug tree-optimization/113922] New: -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922
Bug ID: 113922
Summary: -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3}
generates a false positive for 0-sized structs
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sergiodj at sergiodj dot net
Target Milestone: ---
Hi,
Consider the following example program:
#include
#include
int main(void) {
struct test_st {};
int fd = 0;
int count = 0;
struct test_st test_info[16];
count = read(fd, test_info, sizeof(test_info));
return(0);
}
When compiling it with GCC 13.2 using -D_FORTIFY_SOURCE=3 and -O1, I see:
a.c: In function ‘main’:
a.c:15:13: warning: ‘read’ writing 1 byte into a region of size 0 overflows the
destination [-Wstringop-overflow=]
15 | count = read(fd, test_info, sizeof(test_info));
| ^~
a.c:10:20: note: destination object ‘test_info’ of size 0
10 | struct test_st test_info[16];
|^
In file included from /usr/include/unistd.h:1214,
from a.c:3:
/usr/include/x86_64-linux-gnu/bits/unistd.h:26:1: note: in a call to function
‘read’ declared with attribute ‘access (write_only, 2)’
26 | read (int __fd, void *__buf, size_t __nbytes)
| ^~~~
GCC allows empty structs on C code and they are correctly sized 0, but
-Wstringop-overflow still thinks the code is trying to read 1 byte into the
array, which is not correct.
I know there are a lot of false positives reported against -Wstringop-overflow,
but I couldn't find an exact duplicate of this one.
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805 --- Comment #12 from Sergio Durigan Junior --- Sorry, I have been busy with other things, but I'm paying attention to the developments here. I still have to test the workaround I suggested (passing -fdebug-prefix-map to LDFLAGS) more broadly, because I think I may have found at least one scenario where it doesn't work. Something else that's puzzling me is the fact that I don't see this behaviour everywhere; some packages do have the expected DW_AT_comp_dir even after being compiled with LTO enabled.
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #9 from Sergio Durigan Junior ---
at(In reply to Richard Biener from comment #8)
> This works for me. The consistency check is not fully implemented and
> instead
> of passing down no -fdebug-prefix-map the patch passes the first but warns:
>
> > ./xgcc -B. t.o t2.o -o t
> lto-wrapper: warning: option
> -fdebug-prefix-map=/home/rguenther/obj-trunk-g/gcc=/bbb with different
> values, using /home/rguenther/obj-trunk-g/gcc=/aaa
>
> to make consistency checking work we need to record -fcanon-prefix-map
> and the full set of -f{file,debug}-prefix-map options in order (I think
> file and debug variants can be considered the same) of the first TU and
> compare that to each of the following TUs.
Thanks a lot for the patch. I tried it locally, and it indeed works for the
simple example I posted in the description of this bug. However, for some
reason it doesn't seem to make a difference for the vim compilation. I'm still
seeing a directory table like the following:
Directory table:
[path(line_strp)]
0 /home/ubuntu/vim/vim-9.0.1378/src/vim-basic (0)
1 /usr/include/x86_64-linux-gnu/bits (57)
2 /usr/include (92)
whereas if I pass -fdebug-prefix-map to LDFLAGS, the directory table becomes:
Directory table:
[path(line_strp)]
0 /usr/src/vim-2:9.0.1378-2ubuntu2~ppa1/src/vim-basic (0)
1 /usr/include/x86_64-linux-gnu/bits (65)
2 /usr/include (100)
which is what I expected to see.
> Note a link-time specified option will simply ignore all options from the
> compile-time (but only for the link-time unit, the compile-time debug info
> has already been generated with the originally specified options).
FWIW, I think this bug is related to #108534 (and the related discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606205.html).
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805 --- Comment #6 from Sergio Durigan Junior --- As I mentioned in the description, a workaround for this would be to use -fdebug-prefix-map in LDFLAGS as well. I'm leaning towards implementing this in Ubuntu until we figure out how to properly solve the issue.
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805 --- Comment #5 from Sergio Durigan Junior --- (In reply to Richard Biener from comment #4) > It works for the actual source file translation units for me, it's just the > LTRANS units that have a DW_AT_comp_dir that's not remapped. It's actually > difficult to do the right thing here and I think the correct thing to do if > you don't like the "bogus" DW_AT_comp_dir is to actually specify > -fdebug-prefix-map at link time. > > The issue it's difficult to do the right thing is because you have to > consider > > gcc -c t1.c -flto -fdebug-prefix-map=`pwd`=/ > gcc -c t2.c -flto -fdebug-prefix-map=`pwd`=/ > gcc t1.o t2.o > > now, what DW_AT_comp_dir should the possibly single LTRANS CU use? Thanks for the reply. I understand the problem here. But taking the vim package as an example, the remapping was done to a specific directory, for all object files. > One "fix" might be to emit multiple DWARF CUs for each LTRANS unit and thus > keep the association to the original CUs 1:1 (I have some patches for this > lying around for a few years). But then we're still mixing CUs by means > of inlining and cloning. > > Note the DW_AT_name of the LTRANS CUs is (DWARF doesn't allow > to omit it). What's more "problematic" is that somehow the file list of > the CU contains t.c - it might be worth figuring out how this gets there. > > A pragmatic fix could be to detect the case where all LTO inputs had the > same -fdebug-prefix-map specified and carry that over to link time > automatically in lto-wrapper (we are currently not streaming the various > remapping flags). That'd solve the problem I'm seeing, I believe. > Can you clarify what the actual problem with the generated dwarf is? If we take the vim package as an example (again), the problem I'm seeing is that -fdebug-prefix-map is being used when compiling all .o files, but the generated binary ends up with the old path in its directory table. This confuses debuginfod, which uses this information to determine where the source files are located. It's interesting to note that I also see the new path listed in the DWARF, but for some reason debuginfod/GDB get confused about it. I found yet another package that seems to be affected by this problem: samba. Curiously enough, there are other packages that don't seem to be affected, even though they're also being compiled using LTO.
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #1 from Sergio Durigan Junior ---
The formatting for the example snippet got messed up. Here's a fixed version:
$ echo 'int main(){}' > foo.c
$ ~/gcc/install/bin/gcc -c foo.c -O2 -g -flto=auto -ffat-lto-objects
-fdebug-prefix-map=`pwd`=/aaa -o foo
$ ~/gcc/install/bin/gcc foo -flto=auto -ffat-lto-objects -o bar
[Bug debug/109805] New: LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Bug ID: 109805
Summary: LTO affecting -fdebug-prefix-map
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sergiodj at sergiodj dot net
Target Milestone: ---
Hi,
In Ubuntu we use -fdebug-prefix-map to remap a package's build directory (which
contains random stuff) into a predictable path under /usr/src. This is done in
order to help debuginfod index the source code for our packages.
Things work very well, but I found a weird corner case involving LTO. The
affected package is vim. You can see the build logs for it here:
https://launchpadlibrarian.net/665520301/buildlog_ubuntu-mantic-amd64.vim_2%3A9.0.1378-2ubuntu1_BUILDING.txt.gz
As you can notice, we're using -fdebug-prefix-map and LTO for the build.
The problem is that the resulting debuginfo doesn't have the remaped directory.
I can replicate the issue locally, and at first I thought this was either bug
#108464 or #87726, but after some digging I'm convinced it's something else.
I've compiled gcc (GCC) 14.0.0 20230510 from the master branch
(608e7f3ab47fe746279c552c3574147aa3d8ee76), and I still can reproduce the
problem.
A simple reproducer for the problem follows:
$ echo 'int main(){}' > foo.c $ ~/gcc/install/bin/gcc -c foo.c -O2 -g
-flto=auto -ffat-lto-objects -fdebug-prefix-map=`pwd`=/aaa -o foo $
~/gcc/install/bin/gcc foo -flto=auto -ffat-lto-objects -o bar
A workaround for this bug is to either stop using LTO or explicitly set
-fdebug-prefix-map when linking the object.
[Bug debug/87726] -fdebug-prefix-map doesn't work with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726 Sergio Durigan Junior changed: What|Removed |Added CC||sergiodj at sergiodj dot net --- Comment #3 from Sergio Durigan Junior --- FWIW, this is working for me (GCC 12). I'm investigating another bug with -fdebug-prefix-map and LTO, and thought this one would be related.
[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316 Sergio Durigan Junior changed: What|Removed |Added CC||sergiodj at sergiodj dot net --- Comment #3 from Sergio Durigan Junior --- I can confirm this bug. We're facing the problem when compiling NSS on Ubuntu Kinetic (development version) on ppc64el, because the build uses -O3.
