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@xxxxxxxxx> 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@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
