HIWARE Compiler and gdb4.17

[tcombs@urbana.css.mot.com (Tim Combs)]

Good morning,

I am working on integrating gdb (4.17)  into a simulator project
we have here.  The binaries we want to debug are elf/dwarf2
binaries generated from the HICROSS compiler from HIWAVE 
for the 68HC12.

From what I see in a binary and comparing what I read in
the Dwarf2 (1.1) spec, they don't implement .debug_line
correctly, it seems they forget to include a directory
table and then put an entry in the filenames table
called HIWARE.  But that's not the problem that's really
bugging me (pun intended).

When I try to set a breakpoint in this binary I get a 
core dump.  Here is the back trace:

core was generated by `./gdb namps4.abs'.
Program terminated with signal 11, Segmentation fault.
find_solib: Can't read pathname for load map: Input/output error

#0  decode_locdesc (blk=0x8ec, objfile=0x815bb90) at dwarf2read.c:5622
#1  0x809383a in read_func_scope (die=0x82128c0, objfile=0x815bb90) at dwarf2read.c:1593
#2  0x8093502 in process_die (die=0x82128c0, objfile=0x815bb90) at dwarf2read.c:1385
#3  0x8093752 in read_file_scope (die=0x8233598, objfile=0x815bb90) at dwarf2read.c:1545
#4  0x80934ef in process_die (die=0x8233598, objfile=0x815bb90) at dwarf2read.c:1381
#5  0x809334f in psymtab_to_symtab_1 (pst=0x819418c) at dwarf2read.c:1326
#6  0x809323d in dwarf2_psymtab_to_symtab (pst=0x819418c) at dwarf2read.c:1267
#7  0x8065647 in psymtab_to_symtab (pst=0x819418c) at symfile.c:309
#8  0x80624f5 in find_pc_sect_symtab (pc=15761744, section=0x815a224) at symtab.c:1182
#9  0x8061d0c in lookup_symbol (name=0xbffff800 "au_Dtmf", block=0x0, namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0xbffff848) at symtab.c:693
#10 0x8063982 in decode_line_1 (argptr=0xbffff918, funfirstline=1, default_symtab=0x0, default_line=0, canonical=0xbffff8f8) at symtab.c:2464
#11 0x804ccf0 in break_command_1 (arg=0x8147f45 "", flag=0, from_tty=1) at breakpoint.c:2497
#12 0x804d0d8 in break_command (arg=0x8147f3e "au_Dtmf", from_tty=1) at breakpoint.c:2660
#13 0x80b5c2d in execute_command (p=0x8147f44 "f", from_tty=1) at top.c:1259
#14 0x80b5db6 in command_loop () at top.c:1339
#15 0x80bbac5 in main (argc=2, argv=0xbffffaac) at main.c:554

What seems to be  happening is the decode_locdesc is passed
0x8ec which is the value of the DW_AT_framebuffer in the 
binary.  This is the value of *buf in attrs which is an invalid
memory location.  My question is:

dwarf2_read_abbrevs assigns *blk the value of DW_AT_framebuffer
Shouldn't the blk structure in attrs be populated with the size 
of the entry in the .debug_loc and a char * pointing to it 
-or- am I wrong  and did I read the spec wrong
-or- did the compiler people not implement this correctly
-or- all of the above.


I hope this makes sense and sorry it is so long.

Thanks
Tim
-- 
--------------------------------------------------------
 Simulation Technologies
 Urbana Design Center
 Motorola CSS
 217-384-8549 (Voice)
 217-384-8550 (Fax)
 Tim Combs
 tcombs@urbana.css.mot.com