Bug 15325 - crashes with "segmentation fault" for self-created dwarf-file
Summary: crashes with "segmentation fault" for self-created dwarf-file
Status: RESOLVED DUPLICATE of bug 14983
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.5
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-30 12:48 UTC by smarf
Modified: 2013-04-12 17:44 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
floppy disk image and dwarf debug info (16.37 KB, application/x-gzip)
2013-03-30 12:48 UTC, smarf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description smarf 2013-03-30 12:48:28 UTC
Created attachment 6961 [details]
floppy disk image and dwarf debug info

I tried to build a dwarf-file for a bootable image (see attached file floppy.img which can be started via "qemu -fda floppy.img -boot a -s"). This dwarf-file (see attached file dwarf) seems to be ok for readelf and dwarfdump, but not for gdb. 

Starting gdb with "gdb --se=dwarf" and connecting to qemu with "target remote :1234", I get "0x001045ea in ?? (warning: (Internal error: pc 0x1045ea in read in psymtab, but not in symtab.)" from gdb 7.1 and "Segmentation fault" from gdb 7.5.1 without anything else.

I would expect gdb to recognize 0x1045ea as being in Kernel.main as "dwarfdump -a -vv" shows
<0><   11>	DW_TAG_compile_unit <abbrev 1>
		DW_AT_name                  Kernel
		DW_AT_producer              SJC
		DW_AT_language              DW_LANG_C
		DW_AT_low_pc                0x104320
		DW_AT_high_pc               0x108dd9
<0><   30>	DW_TAG_subprogram <abbrev 2>
		DW_AT_name                  main
		DW_AT_external              yes(1)
		DW_AT_low_pc                0x104320
		DW_AT_high_pc               0x1045ed

I think giving "Segmentation fault" is a bug in gdb. Additionally, if anyone can suggest changes to get gdb accepting it, I would be very happy.

Thanks in advance! :-)
Comment 1 smarf 2013-03-31 20:16:13 UTC
A colleague found the causing line:
    at buildsym.c:454
    454      if (start != BLOCK_START (block)
block is 0, the access in BLOCK_START will result in segv.
Comment 2 Tom Tromey 2013-04-12 17:44:23 UTC
Dup.

*** This bug has been marked as a duplicate of bug 14983 ***