[Crash-utility] is crash 7.1.8 meant to support CONFIG_DEBUG_INFO_SPLIT=y / CONFIG_DEBUG_INFO_DWARF4=y kernel builds?
Jason Vas Dias
jason.vas.dias at gmail.com
Thu Feb 23 11:35:53 UTC 2017
Aha! I just realized I can do (tried) :
$ gdb vmlinux /proc/kcore
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 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 vmlinux...done.
[New process 1]
Core was generated by `BOOT_IMAGE=/vmlinuz-4.10.0 root=/dev/OS/linux
rd.lvm.lv=OS/linux ro i915.modese'.
#0 0x0000000000000000 in irq_stack_union ()
warning: File "/usr/build/linux/linux-4.10/scripts/gdb/vmlinux-gdb.py"
auto-loading has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/build/linux/linux-4.10/scripts/gdb/vmlinux-gdb.py
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) p vsyscall_gtod_data
$1 = {seq = 7789770, vclock_mode = 1, cycle_last = 22630991615017,
mask = 18446744073709551615, mult = 5798665, shift = 24,
wall_time_snsec = 15532746196817975, wall_time_sec = 1487849612,
monotonic_time_sec = 7804,
monotonic_time_snsec = 5062208047454263, wall_time_coarse_sec =
1487849612, wall_time_coarse_nsec = 925823819,
monotonic_time_coarse_sec = 7804, monotonic_time_coarse_nsec =
301731112, tz_minuteswest = 0, tz_dsttime = 0}
(gdb)
this is all I needed at this time.
But it would be nice to be able to use crash's special features with a
split-debuginfo
dwarf-4 kernel.
On 23/02/2017, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
> Oops -
> $ objdump -fh head64.dwo
>
> head64.dwo: file format elf64-x86-64
> architecture: i386:x86-64, flags 0x00000010:
> HAS_SYMS
> start address 0x0000000000000000
>
> Sections:
> Idx Name Size VMA LMA File off
> Algn
> 0 .debug_info.dwo 0000ac4a 0000000000000000 0000000000000000 00000040
> 2**0
> CONTENTS, READONLY, DEBUGGING, EXCLUDE
> 1 .debug_abbrev.dwo 00000637 0000000000000000 0000000000000000
> 00006fd9 2**0
> CONTENTS, READONLY, DEBUGGING, EXCLUDE
> 2 .debug_loc.dwo 00000266 0000000000000000 0000000000000000 0000725b
> 2**0
> CONTENTS, READONLY, DEBUGGING, EXCLUDE
> 3 .debug_line.dwo 00000850 0000000000000000 0000000000000000 00007374
> 2**0
> CONTENTS, READONLY, DEBUGGING, EXCLUDE
> 4 .debug_str_offsets.dwo 000025f0 0000000000000000
> 0000000000000000 000076eb 2**0
> CONTENTS, READONLY, DEBUGGING, EXCLUDE
> 5 .debug_str.dwo 000071c1 0000000000000000 0000000000000000 00008514
> 2**0
>
>
> The offset 64 is correct .
> But the versions are definitely within range and not 0, so something
> else has gone
> wrong to end up with a DWARF header version of 0 :
>
>
>
> $ readelf --debug-dump head64.dwo | head -8
> Contents of the .debug_info.dwo section:
>
> Compilation Unit @ offset 0x0:
> Length: 0xac46 (32-bit)
> Version: 4
> Abbrev Offset: 0x0
> Pointer Size: 8
> <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>
>
> ie. this is a valid .dwo file, readable by binutil-2.27 BFD ,
> but gdb-7.6 BFD is just getting things wrong.
>
>
> On 23/02/2017, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
>> I guess I answered my own question - the answer is : NO ??
>> I guess a more modern *.dwo format is being used that is not
>> understood by the version of bfd used by gdb-7.6 .
>> Debugging crash with gdb 7.11.1 shows BFD is getting
>> the section offsets wrong :
>>
>> $ gdb --args crash $BLD/linux-4.10/vmlinux /proc/kcore
>> GNU gdb (GDB) 7.11.1
>> ...
>> (gdb) b dwarf2read.c:3972
>> (gdb) c
>> Breakpoint 2, error_check_comp_unit_head
>> (header=header at entry=0x7fffffffd078,
>> abbrev_section=abbrev_section at entry=0x28c91b0, section=0x28c9290,
>> section=0x28c9290) at dwarf2read.c:3972
>> 3972 error (_("Dwarf Error: wrong version in compilation unit header
>> "
>> (gdb) where
>> #0 error_check_comp_unit_head (header=header at entry=0x7fffffffd078,
>> abbrev_section=abbrev_section at entry=0x28c91b0, section=0x28c9290,
>> section=0x28c9290) at dwarf2read.c:3972
>> #1 0x00000000006f1106 in read_and_check_comp_unit_head
>> (header=header at entry=0x7fffffffd078, section=section at entry=0x28c9290,
>> abbrev_section=abbrev_section at entry=0x28c91b0, info_ptr=0x7ffff7f4704b
>> "",
>> info_ptr at entry=0x7ffff7f47040 "\001", is_debug_types_section=0) at
>> dwarf2read.c:4018
>> #2 0x00000000006f11f2 in init_cutu_and_read_dies_no_follow
>> (this_cu=this_cu at entry=0x7fffffffd270,
>> abbrev_section=abbrev_section at entry=0x28c91b0,
>> dwo_file=dwo_file at entry=0x28c91a0,
>> die_reader_func=die_reader_func at entry=0x6f5110
>> <create_dwo_debug_info_hash_table_reader>,
>> data=data at entry=0x7fffffffd240) at dwarf2read.c:4829
>> #3 0x00000000006f34e8 in create_dwo_debug_info_hash_table
>> (dwo_file=0x28c91a0) at dwarf2read.c:8394
>> #4 open_and_init_dwo_file (comp_dir=<optimized out>,
>> dwo_name=0x7ffff7f4ecd4 "arch/x86/kernel/head64.dwo") at
>> dwarf2read.c:8978
>> #5 lookup_dwo_cutu (dwo_name=dwo_name at entry=0x7ffff7f4ecd4
>> "arch/x86/kernel/head64.dwo", comp_dir=<optimized out>,
>> signature=signature at entry=13748681403860065761,
>> is_debug_types=is_debug_types at entry=0, this_unit=0x1f277d0)
>> at dwarf2read.c:9182
>> #6 0x00000000006f410f in lookup_dwo_comp_unit
>> (signature=13748681403860065761, comp_dir=<optimized out>,
>> dwo_name=0x7ffff7f4ecd4 "arch/x86/kernel/head64.dwo",
>> this_cu=0x1f277d0) at dwarf2read.c:9237
>> #7 init_cutu_and_read_dies (this_cu=this_cu at entry=0x1f277d0,
>> abbrev_table=abbrev_table at entry=0x0,
>> use_existing_cu=use_existing_cu at entry=0, keep=keep at entry=0,
>> die_reader_func=die_reader_func at entry=0x702420
>> <process_psymtab_comp_unit_reader>, data=data at entry=0x7fffffffd4ac) at
>> dwarf2read.c:4656
>> #8 0x00000000006f8cc8 in process_psymtab_comp_unit
>> (this_cu=0x1f277d0, want_partial_unit=0) at dwarf2read.c:5053
>> #9 0x0000000000709e44 in dwarf2_build_psymtabs_hard
>> (objfile=<optimized out>) at dwarf2read.c:5548
>> #10 dwarf2_build_psymtabs (objfile=0x1639970) at dwarf2read.c:3855
>> #11 0x000000000067bc0e in require_partial_symbols
>> (objfile=objfile at entry=0x1639970, verbose=verbose at entry=0) at
>> psymtab.c:92
>> #12 0x0000000000682644 in read_symbols
>> (objfile=objfile at entry=0x1639970, add_flags=add_flags at entry=4) at
>> symfile.c:862
>> #13 0x00000000006819dc in syms_from_objfile_1 (add_flags=4,
>> num_offsets=0, offsets=0x0, addrs=<optimized out>, objfile=0x1639970)
>> at symfile.c:1045
>> #14 syms_from_objfile (objfile=0x1639970, addrs=<optimized out>,
>> offsets=0x0, num_offsets=0, add_flags=4) at symfile.c:1063
>> #15 0x0000000000681f14 in symbol_file_add_with_addrs_or_offsets
>> (abfd=abfd at entry=0x162c590, add_flags=add_flags at entry=4,
>> addrs=addrs at entry=0x0, flags=flags at entry=0, parent=parent at entry=0x0,
>> num_offsets=0, offsets=0x0) at symfile.c:1168
>> #16 0x0000000000682085 in symbol_file_add_from_bfd
>> (abfd=abfd at entry=0x162c590, add_flags=add_flags at entry=4,
>> addrs=addrs at entry=0x0, flags=flags at entry=0, parent=parent at entry=0x0)
>> at symfile.c:1258
>> #17 0x00000000006820c8 in symbol_file_add
>> (name=name at entry=0x7fffffffdd99 "/usr/build/linux/linux-4.10/vmlinux",
>> add_flags=4, addrs=addrs at entry=0x0, flags=flags at entry=0) at
>> symfile.c:1274
>> #18 0x0000000000682113 in symbol_file_add_main_1 (args=0x7fffffffdd99
>> "/usr/build/linux/linux-4.10/vmlinux", from_tty=0, flags=0) at
>> symfile.c:1300
>> #19 0x00000000006a6359 in catch_command_errors (command=0x682140
>> <symbol_file_add_main>, arg=arg at entry=0x7fffffffdd99
>> "/usr/build/linux/linux-4.10/vmlinux", from_tty=from_tty at entry=0,
>> mask=mask at entry=6) at exceptions.c:584
>> #20 0x00000000006a8e1d in captured_main
>> (data=data at entry=0x7fffffffd8b0) at main.c:948
>> #21 0x00000000006a6285 in catch_errors (func=func at entry=0x6a7d90
>> <captured_main>, func_args=func_args at entry=0x7fffffffd8b0,
>> errstring=errstring at entry=0x8f412a "", mask=mask at entry=6) at
>> exceptions.c:557
>> #22 0x00000000006a8fbb in gdb_main (args=args at entry=0x7fffffffd8b0) at
>> main.c:1079
>> #23 0x00000000006a9001 in gdb_main_entry (argc=<optimized out>,
>> argv=argv at entry=0x7fffffffda18) at main.c:1099
>> #24 0x00000000004f59af in gdb_main_loop (argc=<optimized out>,
>> argc at entry=3, argv=argv at entry=0x7fffffffda18) at gdb_interface.c:76
>> #25 0x0000000000464d3d in main (argc=3, argv=0x7fffffffda18) at
>> main.c:707
>>
>> (gdb) p *header
>> $3 = {length = 1, version = 0, addr_size = 0 '\000', signed_addr_p = 0
>> '\000', abbrev_offset = {sect_off = 2890530816}, offset_size = 4,
>> initial_length_size = 4, offset = {sect_off = 0}, first_die_offset =
>> {cu_off = 11}}
>>
>> we genuinely have a bad header here, because bfd seems to have got the
>> section offsets wrong:
>>
>> If I do:
>>
>> $ objdump -fh head64.o
>>
>> head64.o: file format elf64-x86-64
>> architecture: i386:x86-64, flags 0x00000011:
>> HAS_RELOC, HAS_SYMS
>> start address 0x0000000000000000
>>
>> Sections:
>> ...
>> Idx Name Size VMA LMA File off
>> Algn
>> 11 .debug_info 00000034 0000000000000000 0000000000000000 00000593
>> 2**0
>> CONTENTS, RELOC, READONLY, DEBUGGING
>> 12 .debug_abbrev 0000001d 0000000000000000 0000000000000000 000005c7
>> 2**0
>> CONTENTS, READONLY, DEBUGGING
>> ...
>>
>> So the .debug_info section we are looking at should begin at file
>> offset 0x593 = 1427, right ?
>>
>> But the bfd has the section offsets wrong :
>>
>> (gdb) p *section->asection
>> $40 = {name = 0x28c2ba3 ".debug_info.dwo", id = 139, index = 0, next =
>> 0x28c2f70, prev = 0x0, flags = 41224, user_set_vma = 1, linker_mark =
>> 0, linker_has_input = 0, gc_mark = 0, compress_status = 0,
>> segment_mark = 0, sec_info_type = 0,
>> use_rela_p = 1, sec_flg0 = 0, sec_flg1 = 0, sec_flg2 = 0, sec_flg3 =
>> 0, sec_flg4 = 0, sec_flg5 = 0, vma = 0, lma = 0, size = 28569, rawsize
>> = 0, compressed_size = 0, relax = 0x0, relax_count = 0, output_offset
>> = 0,
>> output_section = 0x0, alignment_power = 0, relocation = 0x0,
>> orelocation = 0x0, reloc_count = 0, filepos = 64, rel_filepos = 0,
>> line_filepos = 0, userdata = 0x28c53d8, contents = 0x0, lineno = 0x0,
>> lineno_count = 0, entsize = 0,
>> kept_section = 0x0, moving_line_filepos = 0, target_index = 0,
>> used_by_bfd = 0x28c2c10, constructor_chain = 0x0, owner = 0x2465c10,
>> symbol = 0x28c2ce8, symbol_ptr_ptr = 0x28c2f38, map_head = {link_order
>> = 0x0, s = 0x0}, map_tail = {
>> link_order = 0x0, s = 0x0}}
>>
>> 'filepos=64' does not correspond to any section header offset or section
>> offset
>> in the file .
>>
>> Oh well, I'll just have to rebuild kernel without
>> CONFIG_DEBUG_INFO_SPLIT=y / CONFIG_DEBUG_INFO_DWARF4=y
>> .
>> This is a shame - the massive decrease in overall build size makes
>> building kernels
>> a much less daunting task on my limited storage machine .
>> I hope crash's bfd is upgraded to handle the modern .dwo format from gcc
>> 5.4.0 +
>> binutils-2.27 soon.
>> Is crash ever going to migrate to gdb-7.11.1+ ?
>>
>> Regards,
>> Jason
>>
>> On 23/02/2017, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
>>> Hi -
>>> I have these kernel config options set for a successful kernel build :
>>>
>>> $ grep DEBUG_INFO .config
>>> CONFIG_DEBUG_INFO=y
>>> # CONFIG_DEBUG_INFO_REDUCED is not set
>>> CONFIG_DEBUG_INFO_SPLIT=y
>>> CONFIG_DEBUG_INFO_DWARF4=y
>>>
>>> This splits debug_info sections into separate ${X}.dwo files for each
>>> kernel
>>> object produced.
>>>
>>> I modified several files and did a 'make bzImage' , which succeeded,
>>> and installed the kernel, and tried to run crash-7.1.8 to inspect a
>>> few things, but it says:
>>> <quote><pre>
>>> $ crash vmlinuz /proc/kcore
>>> ....
>>> gdb called without error_hook: Dwarf Error: wrong version in
>>> compilation unit header (is 0, should be 2, 3, or 4) [in module
>>> /usr/build/linux/linux-4.10/arch/x86/kernel/head64.dwo]
>>> Dwarf Error: wrong version in compilation unit header (is 0, should be
>>> 2, 3, or 4) [in module
>>> /usr/build/linux/linux-4.10/arch/x86/kernel/head64.dwo]
>>>
>>> crash: vmlinux: no debugging data available
>>> </pre></quote>
>>>
>>> But the files still exist from the build:
>>> -rw-r--r-- 1 root root 47784 Feb 21 20:07
>>> /usr/build/linux/linux-4.10/arch/x86/kernel/head64.dwo
>>> -rw-r--r-- 1 root root 17072 Feb 21 20:07
>>> /usr/build/linux/linux-4.10/arch/x86/kernel/head64.o
>>> in the same directory as the head64.c file .
>>>
>>> I thought the whole point of 'vmlinux' was that it contained the
>>> debug_info
>>> ?
>>> Do I need to re-link a vmlinux.dbg with all the *.dwo files
>>> corresponding to each '*.o' file vmlinux contains , and vmlinux?
>>> If so, then I don't see much point in the 'CONFIG_DEBUG_INFO_SPLIT=y'
>>> option. Shouldn't a 'vmlinux.dwo' file be produced, containing all
>>> concatenated
>>> debug_info sections for 'vmlinux' ?
>>> I guess crash just doesn't support
>>> CONFIG_DEBUG_INFO_SPLIT=y / CONFIG_DEBUG_INFO_DWARF4=y ?
>>>
>>> Sorry for the newbie type question. Please respond to :
>>> jason.vas.dias at gmail.com
>>> I'm not a member of the list.
>>>
>>> Thanks & Regards,
>>> Jason
>>>
>>
>
More information about the Crash-utility
mailing list