HIWARE Compiler and gdb4.17

HIWARE Compiler and gdb4.17

[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

Re: HIWARE Compiler and gdb4.17

[Peter.Schauer]

What are you getting from
f 1
p *attr

The content of *attr should have been filled in via read_attribute,
which switches on abbrev->form. I suspect that the DW_AT_frame_base
attribute does have an unusual DW_FORM_*, but I don't have the dwarf2
specs with me at the moment...

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


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de