malloc() fails to fail correctly at -O1 or above #5837
Labels
bugzilla
Issues migrated from bugzilla
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
Comments
|
This is fixed on mainline. |
MaskRay
added a commit
that referenced
this issue
Feb 3, 2023
Fix #60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136
llvmbot
pushed a commit
to llvm/llvm-project-release-prs
that referenced
this issue
Feb 3, 2023
Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136 (cherry picked from commit 08c915f)
CarlosAlbertoEnciso
pushed a commit
to SNSystems/llvm-debuginfo-analyzer
that referenced
this issue
Feb 4, 2023
Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136
tstellar
pushed a commit
to llvm/llvm-project-release-prs
that referenced
this issue
Feb 6, 2023
Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136 (cherry picked from commit 08c915f)
skatrak
pushed a commit
to skatrak/llvm-project-rocm
that referenced
this issue
Feb 10, 2023
Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extended Description
consider the following:
$ cat test.c
#include <stdlib.h>
#include <stdio.h>
int main() {
size_t size = 0;
size = ~size;
int * a = malloc(size);
if(a)
printf("Successfully allocated %lX bytes of memory at %lX.\n",size,a);
else
printf("Failed to allocate %lX bytes of memory.\n",size);
}
$ clang -O0 test.c -o test.O0 && ./test.O0
Failed to allocate FFFFFFFFFFFFFFFF bytes of memory.
$ clang -O1 test.c -o test.O1 && ./test.O1
Successfully allocated FFFFFFFFFFFFFFFF bytes of memory at 7FD4D15BA010.
distro is Gentoo ~amd64. glibc is version 2.11 and compiled with gcc.
Apologies if this is a dupe, or caused by gcc compiled glibc conflicts. I'm not quite sure exactly what to search for, but searching for 'malloc' didn't appear to find anything relevant.
The text was updated successfully, but these errors were encountered: