https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
Bug ID: 92410
Summary: Invalid access to df->insns[] in
regstat_bb_compute_calls_crossed (caught by hwasan)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu
Build: aarch64-none-linux-gnu
On trying to rebase the hwasan patches to a newer GCC version, I've found that
hwasan catches a bug newly introduced between commits r275833 and r277678.
The stack trace of the access (as given by hwasan) is:
#0 0x6293ac in SigTrap<3>
../../../../gcc/libsanitizer/hwasan/hwasan_checks.h:27
#1 0x6293ac in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 3>
../../../../gcc/libsanitizer/hwasan/hwasan_checks.h:88
#2 0x6293ac in __hwasan_load8
../../../../gcc/libsanitizer/hwasan/hwasan.cpp:478
#3 0x10cff94 in regstat_bb_compute_calls_crossed
../../gcc/gcc/regstat.c:327
#4 0x10cff94 in regstat_compute_calls_crossed() ../../gcc/gcc/regstat.c:379
#5 0x21c0858 in sched_init() ../../gcc/gcc/haifa-sched.c:7337
#6 0x21d3994 in haifa_sched_init() ../../gcc/gcc/haifa-sched.c:7354
#7 0x11376c8 in schedule_insns() ../../gcc/gcc/sched-rgn.c:3514
#8 0x1138584 in rest_of_handle_sched2 ../../gcc/gcc/sched-rgn.c:3746
#9 0x1138584 in execute ../../gcc/gcc/sched-rgn.c:3882
#10 0x102911c in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2494
#11 0x1029c58 in execute_pass_list_1 ../../gcc/gcc/passes.c:2580
#12 0x1029c74 in execute_pass_list_1 ../../gcc/gcc/passes.c:2581
#13 0x1029c74 in execute_pass_list_1 ../../gcc/gcc/passes.c:2581
#14 0x1029cd0 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2591
#15 0x955aa4 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2196
#16 0x956f38 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2334
#17 0x956f38 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2684
#18 0x95ac58 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2597
#19 0x95ac58 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2864
#20 0x1209bf8 in compile_file ../../gcc/gcc/toplev.c:481
#21 0x61e9d4 in do_compile ../../gcc/gcc/toplev.c:2199
#22 0x61e9d4 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2334
#23 0x621758 in main ../../gcc/gcc/main.c:39
#24 0xffff8b46889c in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f89c)
While the stack trace of the allocation aronud this address (as given by
hwasan) is:
[0xefe600008400,0xefe600008500) is a small allocated heap chunk; size: 256
offset: 240
0xefe6000084f0 is located 0 bytes to the right of 240-byte region
[0xefe600008400,0xefe6000084f0)
allocated here:
#0 0x62ae0c in __sanitizer_malloc
../../../../gcc/libsanitizer/hwasan/hwasan_interceptors.cpp:169
#1 0x24b3df8 in xrealloc ../../gcc/libiberty/xmalloc.c:177
#2 0x99c434 in df_grow_insn_info() ../../gcc/gcc/df-scan.c:545
#3 0x99e928 in df_scan_alloc(bitmap_head*) ../../gcc/gcc/df-scan.c:262
#4 0xe34ee0 in do_reload ../../gcc/gcc/ira.c:5574
#5 0xe34ee0 in execute ../../gcc/gcc/ira.c:5697
#6 0x102911c in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2494
#7 0x1029c58 in execute_pass_list_1 ../../gcc/gcc/passes.c:2580
#8 0x1029c74 in execute_pass_list_1 ../../gcc/gcc/passes.c:2581
#9 0x1029cd0 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2591
#10 0x955aa4 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2196
#11 0x956f38 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2334
#12 0x956f38 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2684
#13 0x95ac58 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2597
#14 0x95ac58 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2864
#15 0x1209bf8 in compile_file ../../gcc/gcc/toplev.c:481
#16 0x61e9d4 in do_compile ../../gcc/gcc/toplev.c:2199
#17 0x61e9d4 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2334
#18 0x621758 in main ../../gcc/gcc/main.c:39
#19 0xffff8b46889c in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f89c)
#20 0x624e34
(/home/ubuntu/working-directory/gcc-objdir-hwasan/gcc/cc1+0x624e34)
I've verified the bug by compiling on r277678 and viewing the relevent command
in gdb.
After running a full bootstrap (convert filenames as relevent):
/home/ubuntu/working-directory/gcc-objdir/./gcc/xgcc
-B/home/ubuntu/working-directory/gcc-objdir/./gcc/
-B/home/ubuntu/working-directory/gcc-install/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/working-directory/gcc-install/aarch64-unknown-linux-gnu/lib/
-isystem
/home/ubuntu/working-directory/gcc-install/aarch64-unknown-linux-gnu/include
-isystem
/home/ubuntu/working-directory/gcc-install/aarch64-unknown-linux-gnu/sys-include
-fno-checking -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem
./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC
-I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -o ~/_clzsi2.o
-MT ~/_clzsi2.o -MD -MP -MF ~/_clzsi2.dep -DL_clzsi2 -c
../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS -wrapper
gdb,--args
Then run the following commands in gdb
break make_note_raw if (&x_rtl)->emit.x_cur_insn_uid == 30
run
break regstat_bb_compute_calls_crossed
cont
print df->insns_size
call print_rtx_function((_IO_FILE *)stderr, cfun, true)
You can see that one of the insn uid's is greater than the length of the
current insn array
(gdb) print df->insns_size
$1 = 30
(gdb) call print_rtx_function((_IO_FILE *)stderr, cfun, true)
(function "__clzdi2"
... snip ...
(cinsn 16 (use (reg/i:SI x0)) "../../../gcc/libgcc/libgcc2.c":713:1)
(cnote 30 NOTE_INSN_EPILOGUE_BEG)
(cinsn 25 (use (reg:DI x30)) "../../../gcc/libgcc/libgcc2.c":713:1)
... snip ...
) ;; crtl
) ;; function "__clzdi2"
Which makes sense to make the access within regstat_bb_compute_calls_crossed at
line 327 invalid by one.
struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
I have not yet found the root cause of this problem, and my first attempt at
running `git-bisect` failed. I will try and run `git bisect` with ASAN
enabled bootstrap, as I expect ASAN will also catch this.
For the moment I'm creating this bug in order to reference it in emails.
