This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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