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

Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) #56

Open
vt-alt opened this issue Jul 5, 2020 · 3 comments
Open

Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) #56

vt-alt opened this issue Jul 5, 2020 · 3 comments

Comments

@vt-alt
Copy link

vt-alt commented Jul 5, 2020

I try to introduce crash tool into ALT Linux, but, there is a problem - if vmlinux.debug is eu-elfcompressed (no matter gabi or gnu compressed) - crash is unable to load it with:

4.19.127-rt-alt2.rt54:~# crash

crash 7.2.8.0.21.gc4862e1-alt1
Copyright (C) 2002-2020  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 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-unknown-linux-gnu"...
gdb called without error_hook: Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/usr/lib/debug/lib/modules/4.19.127-rt-alt2.rt54/vmlinux.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4) [in module /usr/lib/debug/usr/lib/debug/lib/modules/4.19.127-rt-alt2.rt54/vmlinux.debug]

crash: /usr/lib/debug/lib/modules/4.19.127-rt-alt2.rt54/vmlinux: no debugging data available

Is it possible to have support for elfcompressed debug into crash? Would it be hard to add?
@vt-alt
Copy link
Author

vt-alt commented Jul 5, 2020

Additional note: I suppose eu-elfcompress's compression is the same in result as with CONFIG_DEBUG_INFO_COMPRESSED kernel option (which is -gz=zlib -Wa,--compress-debug-sections=zlib --compress-debug-sections=zlib).

@k-hagio
Copy link
Contributor

k-hagio commented Jul 7, 2020

The gdb-7.6 that crash contains looks to have some code to handle gnu type compression, but as far as I've tested with eu-elfcompress -t gnu (not gcc -gz=zlib) it didn't work as you said. It would need to patch or rebase the gdb, so I think it would be pretty hard to support it.

k-hagio pushed a commit that referenced this issue Dec 9, 2022
@cdkey @k-hagio
arm64: fix backtraces of KASAN kernel dumpfile truncated
5f27639 
We met "bt" command on KASAN kernel vmcore display truncated backtraces
like this:

  crash> bt
  PID: 4131   TASK: ffff8001521df000  CPU: 3   COMMAND: "bash"
   #0 [ffff2000224b0cb0] machine_kexec_prepare at ffff2000200bff4c

After digging the root cause, it turns out that arm64_in_kdump_text()
found wrong bt->bptr at "machine_kexec" branch.

Disassemble machine_kexec() of KASAN vmlinux (gcc 7.3.0):

  crash> dis -x machine_kexec
  0xffff2000200bff50 <machine_kexec>:     stp     x29, x30, [sp,#-208]!
  0xffff2000200bff54 <machine_kexec+0x4>: mov     x29, sp
  0xffff2000200bff58 <machine_kexec+0x8>: stp     x19, x20, [sp,#16]
  0xffff2000200bff5c <machine_kexec+0xc>: str     x24, [sp,#56]
  0xffff2000200bff60 <machine_kexec+0x10>:        str     x26, [sp,#72]
  0xffff2000200bff64 <machine_kexec+0x14>:        mov     x2, #0x8ab3
  0xffff2000200bff68 <machine_kexec+0x18>:        add     x1, x29, #0x70
  0xffff2000200bff6c <machine_kexec+0x1c>:        lsr     x1, x1, #3
  0xffff2000200bff70 <machine_kexec+0x20>:        movk    x2, #0x41b5, lsl #16
  0xffff2000200bff74 <machine_kexec+0x24>:        mov     x19, #0x200000000000
  0xffff2000200bff78 <machine_kexec+0x28>:        adrp    x3, 0xffff2000224b0000
  0xffff2000200bff7c <machine_kexec+0x2c>:        movk    x19, #0xdfff, lsl #48
  0xffff2000200bff80 <machine_kexec+0x30>:        add     x3, x3, #0xcb0
  0xffff2000200bff84 <machine_kexec+0x34>:        add     x4, x1, x19
  0xffff2000200bff88 <machine_kexec+0x38>:        stp     x2, x3, [x29,#112]
  0xffff2000200bff8c <machine_kexec+0x3c>:        adrp    x2, 0xffff2000200bf000 <swsusp_arch_resume+0x1e8>
  0xffff2000200bff90 <machine_kexec+0x40>:        add     x2, x2, #0xf50
  0xffff2000200bff94 <machine_kexec+0x44>:        str     x2, [x29,#128]
  0xffff2000200bff98 <machine_kexec+0x48>:        mov     w2, #0xf1f1f1f1
  0xffff2000200bff9c <machine_kexec+0x4c>:        str     w2, [x1,x19]
  0xffff2000200bffa0 <machine_kexec+0x50>:        mov     w2, #0xf200
  0xffff2000200bffa4 <machine_kexec+0x54>:        mov     w1, #0xf3f3f3f3
  0xffff2000200bffa8 <machine_kexec+0x58>:        movk    w2, #0xf2f2, lsl #16
  0xffff2000200bffac <machine_kexec+0x5c>:        stp     w2, w1, [x4,#4]

We notice that:
1. machine_kexec() start address is 0xffff2000200bff50
2. the instruction at machine_kexec+0x44 stores the same value
   0xffff2000200bff50 (comes from 0xffff2000200bf000 + 0xf50)
   into stack postion [x29,#128].

When arm64_in_kdump_text() searches for LR from stack, it met
0xffff2000200bff50 firstly, so got wrong bt->bptr.

We know that the real LR is always greater than the start address
of a function, so let's fix it by changing the search conditon to
(*ptr > xxx_start) && (*ptr < xxx_end).

Signed-off-by: Ding Hui <[email protected]>
@mustafaergul0
Copy link

FOR STM32CUBE IDE To ensure all compilation units use the same DWARF version, you need to specify your desired DWARF version in the compiler options of your compiler settings. DWARF is primarily a debugging format used in compiling and debugging programs. The method for doing this is shown in the following 3 screenshots.
Screenshot_2
Screenshot_3
Screenshot_1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@k-hagio @vt-alt @mustafaergul0