[llvm-bugs] Issue 8605 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-05-29 Type: Bug New issue 8605 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8605 Detailed report: https://oss-fuzz.com/testcase?key=5168722837766144 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?" computeKnownBits computeKnownBitsFromOperator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201805251801:201805260721 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5168722837766144 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 17229] x86 FMA could choose different instruction to avoid move
https://bugs.llvm.org/show_bug.cgi?id=17229 Craig Topper changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r327188 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 8599 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unroll
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-05-28 Type: Bug New issue 8599 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unroll https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8599 Detailed report: https://oss-fuzz.com/testcase?key=5634579552534528 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_unroll Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_unroll Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-loop_unroll Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802210603:201802211531 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5634579552534528 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37613] New: Block literal example in Block language spec doesn't compile
https://bugs.llvm.org/show_bug.cgi?id=37613
Bug ID: 37613
Summary: Block literal example in Block language spec doesn't
compile
Product: Documentation
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: General docs
Assignee: unassignedb...@nondot.org
Reporter: spoon.reloa...@gmail.com
CC: llvm-bugs@lists.llvm.org
In the Clang Block language spec, section "Block Literal Expressions"
(https://clang.llvm.org/docs/BlockLanguageSpec.html#block-literal-expressions),
there is an example for block literal syntax that says the following:
Given:
typedef int (*pointerToFunctionThatReturnsIntWithCharArg)(char);
pointerToFunctionThatReturnsIntWithCharArg functionPointer;
^ pointerToFunctionThatReturnsIntWithCharArg (float x) { return
functionPointer; }
and:
^ int ((*)(float x))(char) { return functionPointer; }
are equivalent expressions, [...]
However, the second example, i.e.
^ int ((*)(float x))(char) { return functionPointer; }
does not compile in Clang. It produces the error "function cannot return
function type 'int (char)'".
The following expression does compile:
^ int (*(float x))(char) { return functionPointer; }
I am not sure whether it is the intended one.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6716 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: NumValues == VTs.NumVTs && "NumValues wasn't wide enough for its operands!"
Updates: Labels: Deadline-Approaching Comment #3 on issue 6716 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: NumValues == VTs.NumVTs && "NumValues wasn't wide enough for its operands!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6716#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37612] New: member pointer to base member ignores base offset when pointer is function-local and auto-typed.
https://bugs.llvm.org/show_bug.cgi?id=37612 Bug ID: 37612 Summary: member pointer to base member ignores base offset when pointer is function-local and auto-typed. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: xaxa...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 20348 --> https://bugs.llvm.org/attachment.cgi?id=20348&action=edit code demonstrating bug When a derived class's base class has a non-zero offset, a derived-class pointer-to-member to a base-class member should include this offset. But when the pointer-to-member is both auto-typed and defined inside a function, it appears to ignore the base-class offset. The attached code should produce "0" "0x4". Clang++ produces: "0" "0". GCC correctly produces: "0" "0x4". I believe the base class offset is being treated as zero. (To me, this is an unusually specific bug). llvm/clang from trunk as of 2018/05/28, via git. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37611] New: nullptr check after pointer dereference not removed
https://bugs.llvm.org/show_bug.cgi?id=37611
Bug ID: 37611
Summary: nullptr check after pointer dereference not removed
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: d...@znu.io
CC: llvm-bugs@lists.llvm.org
The following code is the distillation of C++ code expansion. This also
represents a decent performance opportunity for LLVM itself, given that this
bug affects LLVM's casting machinery.
The following code should generate the same assembly, regardless of whether it
is '#if 0' or '#if 1'. The correct code assembly code gen is the '#if 0' case.
The "bad" code generation includes needless nullptr preservation logic *after*
the pointer was dereferenced, thus proving the pointer is not null and need not
be preserved.
struct A { long a; };
struct B { long b; };
struct C : public A, public B { long c; };
struct Other { B *b; };
#if 1
C *cast_wrapper(B *b) {
return static_cast(b);
}
#else
#define cast_wrapper(b) static_cast(b)
#endif
long example(Other *o) {
auto b = o->b;
if (b->b != 42)
__builtin_trap();
return cast_wrapper(b)->a;
}
Here is a diff of the IR output. Negative is "bad" and positive is "good":
@@ -31,21 +20,16 @@
unreachable
; :8: ; preds = %1
- %9 = icmp eq %struct.B* %3, null
- %10 = getelementptr inbounds %struct.B, %struct.B* %3, i64 -1
- %11 = bitcast %struct.B* %10 to %struct.C*
- %12 = select i1 %9, %struct.C* null, %struct.C* %11
- %13 = getelementptr inbounds %struct.C, %struct.C* %12, i64 0, i32 0, i32 0
- %14 = load i64, i64* %13, align 8, !tbaa !10
- ret i64 %14
+ %9 = getelementptr inbounds %struct.B, %struct.B* %3, i64 -1, i32 0
+ %10 = load i64, i64* %9, align 8, !tbaa !10
+ ret i64 %10
}
; Function Attrs: noreturn nounwind
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37610] New: xor %a, C -> xor %a, -1 canonicalization
https://bugs.llvm.org/show_bug.cgi?id=37610
Bug ID: 37610
Summary: xor %a, C -> xor %a, -1 canonicalization
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Clang sometimes generates from
#include
uint8_t and_0(uint32_t cache, uint8_t count) {
return uint8_t(cache) & uint8_t((uint8_t(1) << uint8_t(count)) - uint8_t(1));
}
this
define dso_local zeroext i8 @and_0(unsigned int, unsigned char)(i32, i8
zeroext) local_unnamed_addr #0 {
%3 = zext i8 %1 to i32
%4 = shl i32 1, %3
%5 = add i32 %4, 255
%6 = and i32 %5, %0
%7 = trunc i32 %6 to i8
ret i8 %7
}
Because the constant is not -1, the final code is suboptimal
https://godbolt.org/g/DeY8sr
Should we canonicalize it somehow?
https://rise4fun.com/Alive/sEB
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37609] New: ld.lld crash while linking baremetal ARM .o files
https://bugs.llvm.org/show_bug.cgi?id=37609 Bug ID: 37609 Summary: ld.lld crash while linking baremetal ARM .o files Product: lld Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: eblot...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 20347 --> https://bugs.llvm.org/attachment.cgi?id=20347&action=edit Sample archive to reproduce the crash Hi, Using LLD 6.0.0 (host: macOS, target: armv7em bare metal), LLD crashed (while trying to reproduce a sample example for bug https://bugs.llvm.org/show_bug.cgi?id=37608). I'm not sure the .o file are valid (although they seem), but I guess LLD is not expected to crash even in such an event. $ ./build.sh LLD 6.0.0 (compatible with GNU linkers) 0 ld.lld 0x000101dcf83c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60 1 ld.lld 0x000101dcfe29 PrintStackTraceSignalHandler(void*) + 25 2 ld.lld 0x000101dcb459 llvm::sys::RunSignalHandlers() + 425 3 ld.lld 0x000101dd03f2 SignalHandler(int) + 354 4 libsystem_platform.dylib 0x7fff605e8f5a _sigtramp + 26 5 ld.lld 0x0001022b5345 lld::elf::SyntheticSection::classof(lld::elf::SectionBase const*) + 21 6 ld.lld 0x0001020be645 void lld::elf::OutputSection::finalize >() + 677 7 ld.lld 0x0001022b8fbc (anonymous namespace)::Writer >::finalizeSections() + 7660 8 ld.lld 0x0001022b32d1 (anonymous namespace)::Writer >::run() + 177 9 ld.lld 0x0001022b31ea void lld::elf::writeResult >() + 26 10 ld.lld 0x000101f4f115 void lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&) + 9189 11 ld.lld 0x000101f3fd9d lld::elf::LinkerDriver::main(llvm::ArrayRef, bool) + 3885 12 ld.lld 0x000101f3ea93 lld::elf::link(llvm::ArrayRef, bool, llvm::raw_ostream&) + 4483 13 ld.lld 0x000101c84fdb main + 411 14 libdyld.dylib0x7fff602da015 start + 1 15 libdyld.dylib0x000c start + 2681364472 Stack dump: 0. Program arguments: ld.lld -v --warn-common --gc-sections --no-whole-archive crt0.o main.c.o -Bstatic -T target.ld -o ldtest.elf ./build.sh: line 3: 20137 Segmentation fault: 11 ld.lld -v --warn-common --gc-sections --no-whole-archive crt0.o main.c.o -Bstatic -T target.ld -o ldtest.elf lldb -- /usr/local/opt/arm-none-eabi-llvm/bin/ld.lld -v main.c.o --warn-common --gc-sections --no-whole-archive crt0.o -Bstatic -T target.ld -o ldtest.elf (lldb) target create "/usr/local/opt/arm-none-eabi-llvm/bin/ld.lld" Current executable set to '/usr/local/opt/arm-none-eabi-llvm/bin/ld.lld' (x86_64). (lldb) settings set -- target.run-args "-v" "main.c.o" "--warn-common" "--gc-sections" "--no-whole-archive" "crt0.o" "-Bstatic" "-T" "target.ld" "-o" "ldtest.elf" (lldb) run Process 20169 launched: '/usr/local/opt/arm-none-eabi-llvm/bin/ld.lld' (x86_64) LLD 6.0.0 (compatible with GNU linkers) Process 20169 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20) frame #0: 0x0001003c4c63 ld.lld`lld::elf::InputSectionBase::getLinkOrderDep() const + 19 ld.lld`lld::elf::InputSectionBase::getLinkOrderDep: -> 0x1003c4c63 <+19>: movq 0x20(%rdi), %rax 0x1003c4c67 <+23>: andq $0x80, %rax 0x1003c4c6d <+29>: cmpq $0x0, %rax 0x1003c4c71 <+33>: movq %rdi, -0xe8(%rbp) Target 0: (ld.lld) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20) * frame #0: 0x0001003c4c63 ld.lld`lld::elf::InputSectionBase::getLinkOrderDep() const + 19 frame #1: 0x00010043b645 ld.lld`void lld::elf::OutputSection::finalize >() + 677 frame #2: 0x000100635fbc ld.lld`(anonymous namespace)::Writer >::finalizeSections() + 7660 frame #3: 0x0001006302d1 ld.lld`(anonymous namespace)::Writer >::run() + 177 frame #4: 0x0001006301ea ld.lld`void lld::elf::writeResult >() + 26 frame #5: 0x0001002cc115 ld.lld`void lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&) + 9189 frame #6: 0x0001002bcd9d ld.lld`lld::elf::LinkerDriver::main(llvm::ArrayRef, bool) + 3885 frame #7: 0x0001002bba93 ld.lld`lld::elf::link(llvm::ArrayRef, bool, llvm::raw_ostream&) + 4483 frame #8: 0x00011fdb ld.lld`main + 411 frame #9: 0x7fff602da015 libdyld.dylib`start + 1 frame #10: 0x7fff602da015 libdyld.dylib`start + 1 (lldb) I'm attaching a tiny tarball that reproduces the problem with two lightweight object files. -- You are receiving this mail because: You are on the CC list for the bug._
[llvm-bugs] [Bug 37608] New: LLD does not update section start address
https://bugs.llvm.org/show_bug.cgi?id=37608
Bug ID: 37608
Summary: LLD does not update section start address
Product: lld
Version: unspecified
Hardware: Other
OS: other
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: eblot...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20346
--> https://bugs.llvm.org/attachment.cgi?id=20346&action=edit
Sample code to reproduce the issue
Hi,
Using LLD 6.0.0 (host: macOS, target: armv7em bare metal), it seems LLD fails
to properly compute the start address of some of the successive sections, for
example in the following subset:
.pstack :
{
. = ALIGN(8);
__process_stack_base__ = .;
. += __process_stack_size__;
. = ALIGN(8);
__process_stack_end__ = .;
} > ram0
.mstack :
{
. = ALIGN(8);
__main_stack_base__ = .;
. += __main_stack_size__;
. = ALIGN(8);
__main_stack_end__ = .;
} > ram0
I expect that __main_stack_base__ is given an address equal of greater than
__process_stack_end__.
However:
Stack map with LLVM/LLD
2000 B __main_stack_base__
2000 B __process_stack_base__
While:
Stack map with GNU/LD
2400 B __main_stack_base__
2000 B __process_stack_base__
The proper address can be obtained by forcing the start address this way:
.mstack :
{
. = __process_stack_end__;
. = ALIGN(8);
__main_stack_base__ = .;
. += __main_stack_size__;
. = ALIGN(8);
__main_stack_end__ = .;
} > ram0
but it seems awkward.
I'm attaching a tiny tarball file w/ a build.sh script that reproduces the
issue with a very trivial application.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37607] New: LLD does not create segments for output sections coming after .ARM.attributes in linkerscript
https://bugs.llvm.org/show_bug.cgi?id=37607
Bug ID: 37607
Summary: LLD does not create segments for output sections
coming after .ARM.attributes in linkerscript
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: konstantin.schw...@hightec-rt.com
CC: llvm-bugs@lists.llvm.org
LLD does not create segments for output sections coming after .ARM.attributes
section patterns in linkerscripts.
Consider the following assembler file and linker script:
// test.s
.global _start
_start:
nop
// linker.script
ENTRY(_start)
SECTIONS {
.ARM.attributes : { *(.ARM.attributes) }
.text : {
*(.text*)
}
}
llvm-readelf gives the following output:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf
Al
[ 0] NULL 00 00 00 0 0
0
[ 1] .ARM.attributes ARM_ATTRIBUTES 94 30 00 0 0
1
[ 2] .comment PROGBITS c4 64 01 MS 0 0
1
[ 3] .symtab SYMTAB 000128 30 10 5 2
4
[ 4] .shstrtab STRTAB 000158 3a 00 0 0
1
[ 5] .strtab STRTAB 000192 0d 00 0 0
1
[ 6] .text PROGBITS0010 0001a0 04 00 AX 0 0
4
[...]
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0
Section to Segment mapping:
Segment Sections...
00
[...]
Reordering the output section description into
// linker2.script
ENTRY(_start)
SECTIONS {
.text : {
*(.text*)
}
.ARM.attributes : { *(.ARM.attributes) }
}
gives the expected result:
[...]
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x 0x 0x4 0x4 R E 0x1000
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0
Section to Segment mapping:
Segment Sections...
00 .text
01
[...]
arm-none-eabi-ld.bfd produces the expected output with both linkerscripts.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37606] New: BPF target: incorrectly assumes 8byte pointers even for clang -target i386
https://bugs.llvm.org/show_bug.cgi?id=37606 Bug ID: 37606 Summary: BPF target: incorrectly assumes 8byte pointers even for clang -target i386 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Target Description Classes Assignee: unassignedb...@nondot.org Reporter: schaub.johan...@googlemail.com CC: llvm-bugs@lists.llvm.org Created attachment 20345 --> https://bugs.llvm.org/attachment.cgi?id=20345&action=edit Using pointers LLC mistranslates the "Using pointers" attachment example, derived from linux-kernel-4.9/samples/bpf/ 0: 61 12 18 00 00 00 00 00 r2 = *(u32 *)(r1 + 24) 1: 61 13 1c 00 00 00 00 00 r3 = *(u32 *)(r1 + 28) 2: 67 03 00 00 20 00 00 00 r3 <<= 32 3: 4f 23 00 00 00 00 00 00 r3 |= r2 4: 07 03 00 00 20 00 00 00 r3 += 32 5: bf a1 00 00 00 00 00 00 r1 = r10 6: 07 01 00 00 f8 ff ff ff r1 += -8 7: b7 02 00 00 04 00 00 00 r2 = 4 8: 85 00 00 00 04 00 00 00 call 4 Inspection by "pahole" shows that the load-addresses used in the generated BPF assembly assume the layout of 4.9.0-0.bpo.6-amd64 (8byte pointers, 'dev' is at offset dec 32) rather than 4.9.0-0.bpo.6-686-pae (32byte pointers, 'dev' at offset dec 20), as one would expect, because the LLVM-IR was generated by Clang with "-target i386" and specifies the relevant data sizes as 4 byte rather than 8 byte in the datalayout string The workaround is more than ugly. Currently it consists of storing pointers as u32 on the BPF stack and accessing members using "offsetof", which apparently gets correctly resolved at an earlier stage by clang. #define _MEMBER(TYPE,P,M) (*((typeof(((TYPE*)0)->M)*) (((char*)(P)) + offsetof(TYPE, M /* ... */ dev = (u32)_(_MEMBER(struct sk_buff,skb,dev)) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 8588 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-05-28 Type: Bug New issue 8588 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8588 Detailed report: https://oss-fuzz.com/testcase?key=6308554251173888 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc774acc38 Crash State: clang::DeclContext::lookup clang::DeclContext::using_directives UnqualUsingDirectiveSet::addUsingDirectives Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6308554251173888 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
