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@xxxxxxxxx> 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@entry=0x7fffffffd078,
> abbrev_section=abbrev_section@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@entry=0x7fffffffd078,
> abbrev_section=abbrev_section@entry=0x28c91b0, section=0x28c9290,
> section=0x28c9290) at dwarf2read.c:3972
> #1 0x00000000006f1106 in read_and_check_comp_unit_head
> (header=header@entry=0x7fffffffd078, section=section@entry=0x28c9290,
> abbrev_section=abbrev_section@entry=0x28c91b0, info_ptr=0x7ffff7f4704b
> "",
> info_ptr@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@entry=0x7fffffffd270,
> abbrev_section=abbrev_section@entry=0x28c91b0,
> dwo_file=dwo_file@entry=0x28c91a0,
> die_reader_func=die_reader_func@entry=0x6f5110
> <create_dwo_debug_info_hash_table_reader>,
> data=data@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@entry=0x7ffff7f4ecd4
> "arch/x86/kernel/head64.dwo", comp_dir=<optimized out>,
> signature=signature@entry=13748681403860065761,
> is_debug_types=is_debug_types@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@entry=0x1f277d0,
> abbrev_table=abbrev_table@entry=0x0,
> use_existing_cu=use_existing_cu@entry=0, keep=keep@entry=0,
> die_reader_func=die_reader_func@entry=0x702420
> <process_psymtab_comp_unit_reader>, data=data@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@entry=0x1639970, verbose=verbose@entry=0) at
> psymtab.c:92
> #12 0x0000000000682644 in read_symbols
> (objfile=objfile@entry=0x1639970, add_flags=add_flags@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@entry=0x162c590, add_flags=add_flags@entry=4,
> addrs=addrs@entry=0x0, flags=flags@entry=0, parent=parent@entry=0x0,
> num_offsets=0, offsets=0x0) at symfile.c:1168
> #16 0x0000000000682085 in symbol_file_add_from_bfd
> (abfd=abfd@entry=0x162c590, add_flags=add_flags@entry=4,
> addrs=addrs@entry=0x0, flags=flags@entry=0, parent=parent@entry=0x0)
> at symfile.c:1258
> #17 0x00000000006820c8 in symbol_file_add
> (name=name@entry=0x7fffffffdd99 "/usr/build/linux/linux-4.10/vmlinux",
> add_flags=4, addrs=addrs@entry=0x0, flags=flags@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@entry=0x7fffffffdd99
> "/usr/build/linux/linux-4.10/vmlinux", from_tty=from_tty@entry=0,
> mask=mask@entry=6) at exceptions.c:584
> #20 0x00000000006a8e1d in captured_main
> (data=data@entry=0x7fffffffd8b0) at main.c:948
> #21 0x00000000006a6285 in catch_errors (func=func@entry=0x6a7d90
> <captured_main>, func_args=func_args@entry=0x7fffffffd8b0,
> errstring=errstring@entry=0x8f412a "", mask=mask@entry=6) at
> exceptions.c:557
> #22 0x00000000006a8fbb in gdb_main (args=args@entry=0x7fffffffd8b0) at
> main.c:1079
> #23 0x00000000006a9001 in gdb_main_entry (argc=<optimized out>,
> argv=argv@entry=0x7fffffffda18) at main.c:1099
> #24 0x00000000004f59af in gdb_main_loop (argc=<optimized out>,
> argc@entry=3, argv=argv@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@xxxxxxxxx> 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@xxxxxxxxx
>> I'm not a member of the list.
>>
>> Thanks & Regards,
>> Jason
>>
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
