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
