Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

llvm-objdump 15.0.0 crashes dumping aarch64/musl binary #57707

Closed
kraj opened this issue Sep 13, 2022 · 7 comments
Closed

llvm-objdump 15.0.0 crashes dumping aarch64/musl binary #57707

kraj opened this issue Sep 13, 2022 · 7 comments
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] tools:llvm-objdump

Comments

@kraj
Copy link
Contributor

kraj commented Sep 13, 2022 •
edited by VoltrexKeyva
Loading

attached binary is from go package when built for aarch64/musl using clang 15.0.0, llvm-objdump -p trace fails like below

% ./recipe-sysroot-native/usr/bin/aarch64-yoe-linux-musl/aarch64-yoe-linux-musl-llvm-objdump -p packages-split/go/usr/lib/go/pkg/tool/linux_arm64/trace

packages-split/go/usr/lib/go/pkg/tool/linux_arm64/trace:        file format elf64-littleaarch64

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000010040 paddr 0x0000000000010040 align 2**16
         filesz 0x0000000000000230 memsz 0x0000000000000230 flags r--
  INTERP off    0x0000000000000fe2 vaddr 0x0000000000010fe2 paddr 0x0000000000010fe2 align 2**0
         filesz 0x000000000000001e memsz 0x000000000000001e flags r--
    NOTE off    0x0000000000000f7c vaddr 0x0000000000010f7c paddr 0x0000000000010f7c align 2**2
         filesz 0x0000000000000064 memsz 0x0000000000000064 flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000010000 paddr 0x0000000000010000 align 2**16
         filesz 0x0000000000333c60 memsz 0x0000000000333c60 flags r-x
    LOAD off    0x0000000000340000 vaddr 0x0000000000350000 paddr 0x0000000000350000 align 2**16
         filesz 0x00000000005f4d28 memsz 0x00000000005f4d28 flags r--
    LOAD off    0x0000000000940000 vaddr 0x0000000000950000 paddr 0x0000000000950000 align 2**16
         filesz 0x0000000000045f70 memsz 0x0000000000087270 flags rw-
 DYNAMIC off    0x00000000009401c0 vaddr 0x00000000009501c0 paddr 0x00000000009501c0 align 2**3
         filesz 0x00000000000000f0 memsz 0x00000000000000f0 flags rw-
    TLS off    0x0000000000985f70 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000010 flags r--
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
 UNKNOWN off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags ---

Dynamic Section:
  HASH     0x000000000075b0c0
  SYMTAB   0x000000000075b540
  SYMENT   0x0000000000000018
  STRTAB   0x000000000075b180
  STRSZ    0x00000000000001d1
  RELA     0x000000000075ad18
  RELASZ   0x0000000000000030
  RELAENT  0x0000000000000018
  PLTGOT   0x00000000009502c0
  DEBUG    0x0000000000000000
  NEEDED   libc.so
  PLTREL   0x0000000000000007
  PLTRELSZ 0x0000000000000300
  JMPREL   0x000000000075ad48

Version References:
  required from :
    0x1f000000 0x00 6400
    PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: ./recipe-sysroot-native/usr/bin/aarch64-yoe-linux-musl/aarch64-yoe-linux-musl-llvm-objdump -p packages-split/go/usr/lib/go/pkg/tool/linux_arm64/trace
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
[1]    2713868 segmentation fault (core dumped)   -p packages-split/go/usr/lib/go/pkg/tool/linux_arm64/trace

trace.tar.gz
@kraj
Copy link
Contributor Author

kraj commented Sep 13, 2022

@MaskRay FYI let me know if more info is needed

@MaskRay
Copy link
Member

MaskRay commented Sep 13, 2022

There is a malformed .gnu.version_r in packages-split/go/usr/lib/go/pkg/tool/linux_arm64/trace. Do you know how that is produced? A bug in Go?

I am changing llvm-objdump's verneed dumping code to reuse code for llvm-readobj...

@kraj
Copy link
Contributor Author

kraj commented Sep 13, 2022

its being created by go linker in this file see https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/elf.go

@kraj
Copy link
Contributor Author

kraj commented Sep 13, 2022

if I use gcc to compile the go compiler then llvm-objdump works ok. So perhaps its related to clang 15 used in compiling go compiler

@MaskRay
Copy link
Member

MaskRay commented Sep 13, 2022

Patch: https://reviews.llvm.org/D133751

binutils discussion whether an empty .gnu.version_r is valid: https://sourceware.org/bugzilla/show_bug.cgi?id=29566
Personally I think it should be valid, but Go probably should avoid creating such object files to confuse users.

@EugeneZelenko EugeneZelenko added backend:AArch64 tools:llvm-objdump crash Prefer [crash-on-valid] or [crash-on-invalid] and removed new issue labels Sep 13, 2022
@llvmbot
Copy link
Collaborator

llvmbot commented Sep 13, 2022

@llvm/issue-subscribers-tools-llvm-objdump

@llvmbot
Copy link
Collaborator

llvmbot commented Sep 13, 2022

@llvm/issue-subscribers-backend-aarch64

@MaskRay MaskRay mentioned this issue Sep 14, 2022
Closed
llvmbot pushed a commit to llvm/llvm-project-release-prs that referenced this issue Sep 14, 2022
@MaskRay @llvmbot
[llvm-objdump] Change printSymbolVersionDependency to use ELFFile API
e77d67f 
When .gnu.version_r is empty (allowed by readelf but warned by objdump),
llvm-objdump -p may decode the next section as .gnu.version_r and may crash due
to out-of-bounds C string reference. ELFFile<ELFT>::getVersionDependencies
handles 0-entry .gnu.version_r gracefully. Just use it.

Fix llvm/llvm-project#57707

Differential Revision: https://reviews.llvm.org/D133751

(cherry picked from commit 25394c9)
tru pushed a commit to llvm/llvm-project-release-prs that referenced this issue Sep 15, 2022
@MaskRay @tru
[llvm-objdump] Change printSymbolVersionDependency to use ELFFile API
29d395a 
When .gnu.version_r is empty (allowed by readelf but warned by objdump),
llvm-objdump -p may decode the next section as .gnu.version_r and may crash due
to out-of-bounds C string reference. ELFFile<ELFT>::getVersionDependencies
handles 0-entry .gnu.version_r gracefully. Just use it.

Fix llvm/llvm-project#57707

Differential Revision: https://reviews.llvm.org/D133751

(cherry picked from commit 25394c9)
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
@MaskRay
[llvm-objdump] Change printSymbolVersionDependency to use ELFFile API
bd8afd3 
When .gnu.version_r is empty (allowed by readelf but warned by objdump),
llvm-objdump -p may decode the next section as .gnu.version_r and may crash due
to out-of-bounds C string reference. ELFFile<ELFT>::getVersionDependencies
handles 0-entry .gnu.version_r gracefully. Just use it.

Fix llvm/llvm-project#57707

Differential Revision: https://reviews.llvm.org/D133751

(cherry picked from commit 25394c9d10e73b666f4fa1dff2426824894cce58)
veselypeta pushed a commit to veselypeta/cherillvm that referenced this issue May 10, 2024
@MaskRay
[llvm-objdump] Change printSymbolVersionDependency to use ELFFile API
975b0c2 
When .gnu.version_r is empty (allowed by readelf but warned by objdump),
llvm-objdump -p may decode the next section as .gnu.version_r and may crash due
to out-of-bounds C string reference. ELFFile<ELFT>::getVersionDependencies
handles 0-entry .gnu.version_r gracefully. Just use it.

Fix llvm/llvm-project#57707

Differential Revision: https://reviews.llvm.org/D133751
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] tools:llvm-objdump
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@MaskRay @kraj @EugeneZelenko @llvmbot