HIWARE Compiler and gdb4.17
Peter.Schauer
Peter.Schauer@regent.e-technik.tu-muenchen.de
Thu Apr 30 12:32:00 GMT 1998
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
More information about the Gdb-patches
mailing list