is crash 7.1.8 meant to support CONFIG_DEBUG_INFO_SPLIT=y / CONFIG_DEBUG_INFO_DWARF4=y kernel builds?
6:14 p.m.
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(a)gmail.com
I'm not a member of the list.
Thanks & Regards,
Jason
5:17 a.m.
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(a)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(a)gmail.com
I'm not a member of the list.
Thanks & Regards,
Jason
5:24 a.m.
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(a)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@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(a)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(a)gmail.com
> I'm not a member of the list.
>
> Thanks & Regards,
> Jason
>
5:35 a.m.
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(a)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(a)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@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(a)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(a)gmail.com
>> I'm not a member of the list.
>>
>> Thanks & Regards,
>> Jason
>>
>
10:09 a.m.
----- Original Message -----
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(a)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 ?
CONFIG_DEBUG_INFO_DWARF4 is supported, but as you found out, CONFIG_DEBUG_INFO_SPLIT
is not.
The version of gdb in crash will eventually be updated when it's absolutely
necessary, but there are no current plans to do so. For example, it was
forced to be upgraded to gdb-7.3.1 when kernels started being built with
gcc-4.6.1, which defaulted to using -gdwarf-4. The upgrade to gdb-7.6 was
forced for arm64 support. Unfortunately the upgrade is not a particularly
trivial task.
Dave
2833
days inactive
2833
days old
devel@lists.crash-utility.osci.io
4 comments
2 participants
participants (2)
-
Dave Anderson -
Jason Vas Dias