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