[Bug sanitizer/111620] [RISC-V]fsanitize is not working with c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111620
--- Comment #2 from Akhilesh Kumar ---
with 110036 (CHECK failed) issue is fixed, but Even after patch ASAN unable to
detect corruption like "Use_after_free(heap)","Heap buffer overflow","Stack
buffer overflow" and "Use after scope"
some features like "Double Free" and "Memory leaks" are working after 110036
In all corruption scenarios I am getting "DEADLYSIGNAL"
Seems program jumped to some wild address, which is unknown to AddressSanitizer
#include
using namespace std;
int main()
{
int *p=new int;
delete p;
cout<<*p<
[Bug sanitizer/111620] New: [RISC-V]fsanitize is not working with cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111620
Bug ID: 111620
Summary: [RISC-V]fsanitize is not working with cpp
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello
During ASAN verification I observed most of the ASAN is not working for cpp
sharing logs and sample code.
user@starfive:~/akhilesh/asan$ g++ print.cpp -fsanitize=address
user@starfive:~/akhilesh/asan$ ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==17785==ERROR: AddressSanitizer: SEGV on unknown address 0x00081f468e44 (pc
0x002ae2626c74 bp 0x003ffa3472e0 sp 0x003ffa347210 T0)
==17785==The signal is caused by a WRITE memory access.
#0 0x2ae2626c74 in main (/home/user/akhilesh/asan/a.out+0xc74)
#1 0x3fbdac4b02 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#2 0x3fbdac4baa in __libc_start_main_impl csu/libc-start.c:381
#3 0x2ae2626b6e in _start (/home/user/akhilesh/asan/a.out+0xb6e)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/user/akhilesh/asan/a.out+0xc74) in main
==17785==ABORTING
user@starfive:~/akhilesh/asan$ cat print.cpp
#include
using namespace std;
int main()
{
int arr[10];
arr[5]=8;
cout<
using namespace std;
int main()
{
cout << "Hello";
return 0;
}
=run time logs===
ser@starfive:~/akhilesh/asan$ g++ -g use_after_free.cpp -fsanitize=address
user@starfive:~/akhilesh/asan$ ./a.out
AddressSanitizer: CHECK failed: asan_poisoning.cpp:36 "((AddrIsInMem(addr))) !=
(0)" (0x0, 0x0) (tid=17449)
#0 0x3fb771805c in CheckUnwind
../../../../src/libsanitizer/asan/asan_rtl.cpp:67
#1 0x3fb7730a3a in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86
#2 0x3fb7711dca in __asan::PoisonShadow(unsigned long, unsigned long,
unsigned char) ../../../../src/libsanitizer/asan/asan_poisoning.cpp:36
#3 0x3fb76a2e36 in __asan::AsanMapUnmapCallback::OnMap(unsigned long,
unsigned long) const ../../../../src/libsanitizer/asan/asan_allocator.cpp:246
#4 0x3fb76a2e36 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::MapWithCallback(unsigned long, unsigned long, char const*)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:717
#5 0x3fb76a2e36 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::MapWithCallback(unsigned long, unsigned long, char const*)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:709
#6 0x3fb76a2e36 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned long,
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::RegionInfo*, unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:798
#7 0x3fb76a3246 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned long, unsigned int*,
unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:220
#8 0x3fb76a32bc in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Refill(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
> >::PerClass*,
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>*, unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:103
#9 0x3fb76a353c in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Allocate(__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>*, unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:39
#10 0x3fb76a353c in
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>,
__sanitizer::LargeMmapAllocatorPtrArr
[Bug libstdc++/111323] New: [RISC_V] During Insmod "unknown relocation type 57" type in kernel space observed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111323
Bug ID: 111323
Summary: [RISC_V] During Insmod "unknown relocation type 57"
type in kernel space observed
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
Hello
with gcc 13.1 open source RISC-V Toolchain I observed "unknown relocation type
57" error message during insmod my kernel modules it seems this issue could
occurs in RISC-V when we try to assemble or link a program, and the toolchain
encounters a relocation type that it doesn't recognize or support.
as per latest kernel 6.1 (which i am using code) doesn't support RELOC_NUMBER
(R_RISCV_32_PCREL, 57) .
Here is my sample driver makefile
=
CFLAGSÂ +=-std=gnu11 #with this option getting "unknown relocation type 57"
obj-m := hello.o
hello-y := hello.o
all:
make -C ${KDIR} M=$(PWD) modules
clean:
make -C ${KDIR} M=$(PWD) clean
My dummy drive hello.c
#include
#include
int init_module(void) { printk(KERN_INFO "Hello
world.\n"); return 0; }
void cleanup_module(void) { printk(KERN_INFO "Goodbye
world.\n"); }
MODULE_LICENSE("GPL");
==
Using -std=gnu11 with gcc 13 generates R_RISCV_SET6 relocation in eh_frame
section which is not generated without -std=gnu11 flag even with same compiler
optimisations:
My insmod logs
=
/bin # insmod hello.ko
[ 11.807337] hello: loading out-of-tree module taints kernel.
[ 11.809680] hello: Unknown relocation type 57
insmod: can't insert 'hello.ko': invalid parameter
=
readelf output with -std=gnu11
Relocation section '.rela.eh_frame' at offset 0xb08 contains 10 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
001c 001e0039 R_RISCV_32_PCREL .L0 + 0
0020 001f0023 R_RISCV_ADD32 0022 .L0 + 0
0020 001e0027 R_RISCV_SUB32 .L0 + 0
0031 00200035 R_RISCV_SET6 001a .L0 + 0
0031 00210034 R_RISCV_SUB6 0008 .L0 + 0
0044 00220039 R_RISCV_32_PCREL 0022 .L0 + 0
0048 00230023 R_RISCV_ADD32 0042 .L0 + 0
0048 00220027 R_RISCV_SUB32 0022 .L0 + 0
0059 00240035 R_RISCV_SET6 003c .L0 + 0
0059 00250034 R_RISCV_SUB6 002a .L0 + 0
readelf output without -std=gnu11
Relocation section '.rela.text.unlikely' at offset 0x920 contains 6 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
0008 00190017 R_RISCV_PCREL_HI2 .LC0 + 0
000c 001a0018 R_RISCV_PCREL_LO1 0008 .L0 + 0
0010 00200013 R_RISCV_CALL_PLT _printk + 0
002a 001b0017 R_RISCV_PCREL_HI2 0010 .LC1 + 0
002e 001c0018 R_RISCV_PCREL_LO1 002a .L0 + 0
0032 00200013 R_RISCV_CALL_PLT _printk +
As a workaround i have two options either remove -std=gnu11 and use default
standards (-std=gnu17) or use KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables option
but my query is why such relocations are generated with -std=gnu11
[Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
Bug ID: 97941
Summary: [HWASAN] use After free not working as per expectation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello Matthew
While HWASAN verification feature, Source I taken from GCC11 trunk.
I observed Some HWASAN features are not working as per expectation.
Like use After free, Is this known behaviors/Issue ?
int main() {
char *x = (char*)malloc(10 * sizeof(char*));
free(x);
return x[5];
}
./myhak
HWAddressSanitizer:DEADLYSIGNAL
==1227==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0030 (pc
0x004096c8 bp 0x005f00ae9fe0 sp 0x005f00ae8d10 T1227)
==1227==The signal is caused by a UNKNOWN memory access.
==1227==Hint: address points to the zero page.
#0 0x4096c8 in GetAccessInfo
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
#1 0x4096c8 in HwasanOnSIGTRAP
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:445
#2 0x4096c8 in __hwasan::HwasanOnDeadlySignal(int, void*, void*)
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:470
#3 0x5f00ae9fec ()
#4 0x406918 in __hwasan_load1
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan.cpp:446
#5 0x43815c in main
(/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x43815c)
#6 0x55009830a0 in __libc_start_main ../csu/libc-start.c:308
#7 0x4023c4 (/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x4023c4)
HWAddressSanitizer can not provide additional info.
SUMMARY: HWAddressSanitizer: SEGV
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
in GetAccessInfo
==1227==ABORTING
[Bug rtl-optimization/93730] [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730
--- Comment #3 from Akhilesh Kumar ---
Please find test application to reproduce this issue
bash-3.2# g++ -fdump-tree-all /tmp/akhilesh.cpp
during RTL pass: expand
/tmp/akhilesh.cpp: In function 'int main()':
/tmp/akhilesh.cpp:4:15: internal compiler error: in make_decl_rtl, at
varasm.c:1375
4 | unsigned int iDefaultGammaTable[3][GammaSeedCnt] = {{0,},};
| ^~
libbacktrace could not find executable to open
bash-3.2# cat /tmp/akhilesh.cpp
int Seed=1024;
int main()
{
unsigned int DefaultGammaTable[3][Seed] = {{0,},};
return 0;
}
even same issue is reproducible with below test case also
akhilesh.k@DELL-BUILD10:~$ cat test.c
int abc=1;
int main()
{
int array[1][abc] ={0}; << But work well if we changes from 0 t0 1
return 0;
}
[Bug rtl-optimization/93730] [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730 --- Comment #2 from Akhilesh Kumar --- Working on Arm architecture. I am trying to reproduce the same with sample test case
[Bug rtl-optimization/93730] New: [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730
Bug ID: 93730
Summary: [Bug] internal compiler error: in make_decl_rtl, at
varasm.c:1375
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
Hello
I am Getting "internal compiler error: in make_decl_rtl, at varasm.c:1375"
during RTL optimization, but works fine if i pass value instead of variable
name
#g++ -c -Wno-format-truncation -Wno-narrowing MYTV/Picture.cpp
-I=/usr/include/kernel-headers/ -I=/usr/include/mylog/
-I/usr/include/kernel-interfaces/
during RTL pass: expand
/home/user/MY/Picture.cpp:1521:13: internal compiler error: in make_decl_rtl,
at varasm.c:1375
1521 | int GammaTable[RGB_LAST][SeedCnt] = {{0,},}; /Where my seed count
is 1024
| ^~
but code works fine if i pass direct Value in array
-int GammaTable[RGB_LAST][SeedCnt] = {{0,},};
int GammaTable[RGB_LAST][1024] = {{0,},};
#g++ -c -Wno-format-truncation -Wno-narrowing MYTV/Picture.cpp
-I=/usr/include/kernel-headers/ -I=/usr/include/mylog/
-I/usr/include/kernel-interfaces/
#
Unfortunately I can share Picture.cpp code
but I am trying to reproduce this issue with some sample test application
[Bug c++/92708] New: [Issue] dynamic_cast unexpected behavior in my code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92708
Bug ID: 92708
Summary: [Issue] dynamic_cast unexpected behavior in my code
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
Hello
In below code I used class A and a class B which is derived from A. Now, I did
dynamic_cast I got segmentation fault. same behaviors I observed on ARM also.
is this expected behavior ? or some limitation.
As per below link seems some limitation with shared libraries.
https://gcc.gnu.org/faq.html#dso
akhilesh.k@DELL-BUILD10:$ cat hello.c
#include
#include
using namespace std;
class A
{
public:
A(){}
virtual ~A(){};
};
class B : public A
{
public:
B(){}
virtual ~B(){}
};
int main()
{
A *pa, *pa2;
B *pb, *pb2;
pa = new A;
pb = new B;
delete pb;
pa2 = dynamic_cast(pb);
pb2 = dynamic_cast(pb);
pb2 = dynamic_cast(pa2);
printf("pb2 = %p\n", pb2);
pb2 = dynamic_cast(pa);
printf("pb2 = %p\n", pb2);
delete pa;
delete pb;
return 0;
}
akhilesh.k@DELL-BUILD10:$ g++ -g hello.c
akhilesh.k@DELL-BUILD10:$ gdb a.out
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...done.
(gdb) r
Starting program: /data2/2706/akhilesh.k/a.out
Program received signal SIGSEGV, Segmentation fault.
0x77b33156 in __dynamic_cast () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x77b33156 in __dynamic_cast () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x0040095d in main () at hello.c:29
(gdb)
[Bug sanitizer/91795] New: [UBSAN :- error] with combination of flags (shift and unsigned-integer-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91795
Bug ID: 91795
Summary: [UBSAN :- error] with combination of flags (shift and
unsigned-integer-overflow)
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello
I am working on UBSAN.
When I tried to compile my stack with combination of ubsan checkers I got
"error: void value not ignored as it ought to be" ERROR.
Strange this error occurred when I use combination of flags (shift and
unsigned-integer-overflow)
I reproduced the same error with below sample test application.
Please confirm is issue is related with ubsan,
root@VDBS1454:tmp$ gcc -fsanitize=shift main.c
root@VDBS1454:tmp$ gcc -fsanitize=unsigned-integer-overflow main.c
root@VDBS1454:tmp$ gcc -fsanitize=shift,-fsanitize=unsigned-integer-overflow
main.c
gcc: error: unrecognized argument to -fsanitize= option:
'-fsanitize=unsigned-integer-overflow'
root@VDBS1454:tmp$ gcc -fsanitize=shift, -fsanitize=unsigned-integer-overflow
main.c
main.c: In function 'main':
main.c:5:15: error: void value not ignored as it ought to be
return (x << 1);
~~~^
root@VDBS1454:tmp$ cat main.c
#include
unsigned int main()
{
uint8_t x;
return (x << 1);
//return x*2;
}
root@VDBS1454:tmp$
[Bug lto/91252] [Bug] When use -flto "weak symbol" are converted to "t".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91252 --- Comment #3 from Akhilesh Kumar --- When I used binutils version 2.32 we are getting the same result @akhilesh-ubuntu:~/akhilesh/lto$ gcc -flto -o nornal myapp.c @akhilesh-ubuntu:~/akhilesh/lto$ ./bin/nm -C ./nornal | grep power 00400532 t power @akhilesh-ubuntu:~/akhilesh/lto$ ./bin/nm -V GNU nm (GNU Binutils) 2.32 Copyright (C) 2019 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. @akhilesh-ubuntu:~/akhilesh/lto$
[Bug c/91252] New: [Bug] When use -flto "weak symbol" are converted to "t".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91252
Bug ID: 91252
Summary: [Bug] When use -flto "weak symbol" are converted to
"t".
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
when i use -flto "weak symbol" are converted to "t".
I really don't know whether this is bug or expected behavior, because in GCC
Source i am not able to find the code for this conversion.
@akhilesh-ubuntu:~/akhilesh/lto$ gcc -flto -o nornal myapp.c; nm -C ./nornal |
grep power
00400532 t power
@akhilesh-ubuntu:~/akhilesh/lto$ gcc -o nornal myapp.c; nm -C ./nornal | grep
power
00400532 W power
@akhilesh-ubuntu:~/akhilesh/lto$
@akhilesh-ubuntu:~/akhilesh/lto$ cat myapp.c
#include
#include
int __attribute__((weak)) power(int x);
int power(int x)
{
return x*x;
}
int main(int argc, char **argv)
{
printf("power() = %d\n", power(atoi(argv[1])));
return 0;
}
=
@akhilesh-ubuntu:~/akhilesh/lto$
I am using gcc 8.3.0 version and binutils version is 2.29.1
@akhilesh-ubuntu:~/akhilesh/lto$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-arm-src-snapshot-8.3-2019.03/configure
--disable-multilib
Thread model: posix
gcc version 8.3.0 (Linaro GCC 8.2-2018.08~d
[Bug target/90721] [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721 --- Comment #1 from Akhilesh Kumar --- One more observation same test case getting PASS on x86 root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite# gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto -fgnu89-inline -lm -o builtin-apply-4.exe root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite# ./builtin-apply-4.exe root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite#
[Bug c/90721] New: [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721
Bug ID: 90721
Summary: [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c
test case getting fail
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
Hello
I am working On ARM target: in that
./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail when we
use -flto flag with gcc 8.3 but same test cases getting pass when we run on gcc
6.3
=
bash-3.2# cat ./gcc.dg/torture/stackalign/builtin-apply-4.c
/* PR tree-optimization/20076 */
/* { dg-do run } */
/* { dg-additional-options "-fgnu89-inline" } */
/* { dg-require-effective-target untyped_assembly } */
#include
extern void abort (void);
double
foo (int arg)
{
if (arg != 116)
abort();
return arg + 1;
}
inline double
bar (int arg)
{
foo (arg);
__builtin_return (__builtin_apply ((void (*) ()) foo,
__builtin_apply_args (), 16));
}
int
main (int argc, char **argv)
{
if (bar (116) != 117.0)
printf("hello\n");
return 0;
}
bash-3.2#
=
gcc 8.x Results
bash-3.2# gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto
-fgnu89-inline -lm -o ./builtin-apply-4.exe
bash-3.2# ./builtin-apply-4.exe
hello
bash-3.2#
gcc 6.3 test results
bash-3.2# /bin/gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto
-fgnu89-inline -lm -o ./builtin-apply-4.exe
bash-3.2# ./builtin-apply-4.exe
bash-3.2#
it seems that __builtin_apply returning wrong value
[Bug sanitizer/84208] fsanitize-address-use-after-scope Not working for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208 --- Comment #5 from Akhilesh Kumar --- Please Mark this bug ID as invalid with the same patch I am able to run on ARM also there was issue in My setup only (Sorry for the noise). Test results on ARM (gcc 6.2.1) sh-3.2# out_of_scope = ==3348==ERROR: AddressSanitizer: stack-use-after-scope on address 0xbe35c700 at pc 0x000108e8 bp 0xbe35c6c4 sp 0xbe35c6bc WRITE of size 1 at 0xbe35c700 thread T0 #0 0x108e7 in main /data2/TC/scripts/test2.c:10 #1 0x410768ab in __libc_start_main (/lib/libc.so.6+0x410768ab) Address 0xbe35c700 is located in stack of thread T0 at offset 32 in frame #0 0x107ef in main /data2/TC/scripts/test2.c:3 This frame has 1 object(s): [32, 33) 'my_char' <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: AddressSanitizer stack-use-after-scope /data2/TC/scripts/test2.c:10 in main Shadow bytes around the buggy address: 0x37c6b890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b8c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b8d0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 =>0x37c6b8e0:[f8]f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x37c6b8f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37c6b930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==3348==ABORTING sh-3.2# [SECOS][PSCI] Suspend Start CPU #0
[Bug sanitizer/84208] fsanitize-address-use-after-scope Not working for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208
--- Comment #4 from Akhilesh Kumar ---
Please find Patch and test Case
I tried but unable to attached patch as Attachment :(
My Changes for address-use-after-scope which is working for X86 but not for ARM
target
---
gcc/asan.c | 302 ++--
gcc/asan.h | 66 ++--
gcc/cfgexpand.c | 18 +---
gcc/common.opt | 3 +
gcc/dbgcnt.def | 1 +
gcc/doc/invoke.texi | 15 ++-
gcc/gimple.c| 3 +
gcc/gimple.h| 9 ++
gcc/gimplify.c | 236 +---
gcc/internal-fn.c | 9 ++
gcc/internal-fn.def | 1 +
gcc/opts.c | 27 -
gcc/params.def | 6 ++
gcc/params.h| 2 +
gcc/sanitizer.def | 5 +-
gcc/sanopt.c| 3 +
16 files changed, 607 insertions(+), 99 deletions(-)
diff --git a/gcc/asan.c b/gcc/asan.c
index 0775fc1..089fb7a 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -243,6 +243,22 @@ static unsigned HOST_WIDE_INT asan_shadow_offset_value;
static bool asan_shadow_offset_computed;
static vec sanitized_sections;
+/* Return true if STMT is ASAN_MARK poisoning internal function call. */
+static inline bool
+asan_mark_poison_p (gimple *stmt)
+{
+ return (gimple_call_internal_p (stmt, IFN_ASAN_MARK)
+ && tree_to_uhwi (gimple_call_arg (stmt, 0)) == ASAN_MARK_CLOBBER);
+
+}
+
+/* Set of variable declarations that are going to be guarded by
+ use-after-scope sanitizer. */
+
+static hash_set *asan_handled_variables = NULL;
+
+hash_set *asan_used_labels = NULL;
+
/* Sets shadow offset to value in string VAL. */
bool
@@ -285,6 +301,14 @@ set_sanitized_sections (const char *sections)
}
}
+bool
+asan_sanitize_stack_p (void)
+{
+ return ((flag_sanitize & SANITIZE_ADDRESS)
+ && ASAN_STACK
+ && !asan_no_sanitize_address_p ());
+}
+
/* Checks whether section SEC should be sanitized. */
static bool
@@ -313,22 +337,13 @@ asan_shadow_offset ()
alias_set_type asan_shadow_set = -1;
-/* Pointer types to 1 resp. 2 byte integers in shadow memory. A separate
+/* Pointer types to 1, 2 or 4 byte integers in shadow memory. A separate
alias set is used for all shadow memory accesses. */
-static GTY(()) tree shadow_ptr_types[2];
+static GTY(()) tree shadow_ptr_types[3];
/* Decl for __asan_option_detect_stack_use_after_return. */
static GTY(()) tree asan_detect_stack_use_after_return;
-/* Various flags for Asan builtins. */
-enum asan_check_flags
-{
- ASAN_CHECK_STORE = 1 << 0,
- ASAN_CHECK_SCALAR_ACCESS = 1 << 1,
- ASAN_CHECK_NON_ZERO_LEN = 1 << 2,
- ASAN_CHECK_LAST = 1 << 3
-};
-
/* Hashtable support for memory references used by gimple
statements. */
@@ -931,12 +946,16 @@ static void
asan_init_shadow_ptr_types (void)
{
asan_shadow_set = new_alias_set ();
- shadow_ptr_types[0] = build_distinct_type_copy (signed_char_type_node);
- TYPE_ALIAS_SET (shadow_ptr_types[0]) = asan_shadow_set;
- shadow_ptr_types[0] = build_pointer_type (shadow_ptr_types[0]);
- shadow_ptr_types[1] = build_distinct_type_copy (short_integer_type_node);
- TYPE_ALIAS_SET (shadow_ptr_types[1]) = asan_shadow_set;
- shadow_ptr_types[1] = build_pointer_type (shadow_ptr_types[1]);
+ tree types[3] = { signed_char_type_node, short_integer_type_node,
+ integer_type_node };
+
+ for (unsigned i = 0; i < 3; i++)
+{
+ shadow_ptr_types[i] = build_distinct_type_copy (types[i]);
+ TYPE_ALIAS_SET (shadow_ptr_types[i]) = asan_shadow_set;
+ shadow_ptr_types[i] = build_pointer_type (shadow_ptr_types[i]);
+}
+
initialize_sanitizer_builtins ();
}
@@ -1020,6 +1039,15 @@ asan_function_start (void)
current_function_funcdef_no);
}
+/* Return number of shadow bytes that are occupied by a local variable
+ of SIZE bytes. */
+
+static unsigned HOST_WIDE_INT
+shadow_mem_size (unsigned HOST_WIDE_INT size)
+{
+ return ROUND_UP (size, ASAN_SHADOW_GRANULARITY) / ASAN_SHADOW_GRANULARITY;
+}
+
/* Insert code to protect stack vars. The prologue sequence should be emitted
directly, epilogue sequence returned. BASE is the register holding the
stack base, against which OFFSETS array offsets are relative to, OFFSETS
@@ -1047,7 +1075,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
HOST_WIDE_INT base_offset = offsets[length - 1];
HOST_WIDE_INT base_align_bias = 0, offset, prev_offset;
HOST_WIDE_INT asan_frame_size = offsets[0] - base_offset;
- HOST_WIDE_INT last_offset, last_size;
+ HOST_WIDE_INT last_offset;
int l;
unsigned char cur_shadow_byte = ASAN_STACK_MAGIC_LEFT;
tree str_cst, decl, id;
@@ -1222,10 +1250,10 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
(aoff - prev_offset)
>> ASAN_SHADOW_SHIFT);
prev_offset = aoff;
- for (i = 0; i <
[Bug sanitizer/84208] fsanitize-address-use-after-scope Not working for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208 --- Comment #2 from Akhilesh Kumar --- > Does it work on non-changed gcc 7.2 on arm? Not yet verified because unable to cross compile gcc 7.2. > And with arm do mean arm-linux-gnueabi as the target or aarch64-linux-gnu? I am using arm-*-gnueabi target
[Bug sanitizer/84208] New: fsanitize-address-use-after-scope Not working for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208 Bug ID: 84208 Summary: fsanitize-address-use-after-scope Not working for ARM Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: akhilesh.k at samsung dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Dear All I am working On gcc 6.2.1 i wan't to verify use-after-scope feature for ARM Since 6.2.1 don't support this feature I migrated this feature form 7.1 to 6.2.1. After Migration i observed that this Feature is working for My X86 but bot working one ARM target. Test results on ARM (gcc 6.2.1) bash-3.2# ./out_of_scope bash-3.2# Test results on X86 (gcc 6.2.1) bash-3.2# ./out_of_scope = ==45124==ERROR: AddressSanitizer: stack-use-after-scope on address 0xffe5b560 at pc 0x080486b5 bp 0xffe5b508 sp 0xffe5b4fc WRITE of size 1 at 0xffe5b560 thread T0 #0 0x80486b4 in main /home/abuild/rpmbuild/BUILDROOT/test2.c:10 #1 0xf70123d7 in __libc_start_main (/lib/libc.so.6+0x183d7) #2 0x8048500 (/home/abuild/rpmbuild/BUILDROOT/out_of_scope+0x8048500) Address 0xffe5b560 is located in stack of thread T0 at offset 32 in frame #0 0x80485e9 in main /home/abuild/rpmbuild/BUILDROOT/test2.c:3 This frame has 1 object(s): [32, 33) 'my_char' <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: AddressSanitizer stack-use-after-scope /home/abuild/rpmbuild/BUILDROOT/test2.c:10 in main Shadow bytes around the buggy address: 0x3ffcb650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x3ffcb6a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1[f8]f4 f4 f4 0x3ffcb6b0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffcb6f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==45124==ABORTING Query 1. As per my analysis i think This feature is architecture in dependent (Please correct me if i am wrong) Thanks Akhilesh
[Bug libstdc++/81480] Assertion `ec' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81480 Akhilesh Kumar changed: What|Removed |Added Target||arm Host||x86_64 Build||arm toolchain --- Comment #2 from Akhilesh Kumar --- Common i run run libstdc++ test suite with dejagnu runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
[Bug libstdc++/81480] New: Assertion `ec' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81480 Bug ID: 81480 Summary: Assertion `ec' failed Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: akhilesh.k at samsung dot com Target Milestone: --- While libstdc++ tests verification i found below summary report Is this expected ? Or fixed in latest versions === libstdc++ Summary === # of expected passes10170 # of unexpected failures6 # of expected failures 66 # of unsupported tests 612 runtest completed at Tue Jul 18 10:22:55 2017 --Fail logs Line 8625: FAIL: abi/header_cxxabi.c (test for excess errors) Line 8710: FAIL: experimental/filesystem/iterators/directory_iterator.cc execution test Line 8714: FAIL: experimental/filesystem/iterators/recursive_directory_iterator.cc execution test Line 8734: FAIL: experimental/filesystem/operations/exists.cc execution test Line 8738: FAIL: experimental/filesystem/operations/is_empty.cc execution test Line 8750: FAIL: experimental/filesystem/operations/temp_directory_path.cc execution test testsuite/abi/header_cxxabi.c:21:20: fatal error: cxxabi.h: No such file or directory And others are related with void test01(): Assertion `ec' failed.
