* Re: DWARF2 PE/COFF port and parsing ? [not found] <Pine.GSO.4.44.0305201745440.22269-100000@eos> @ 2003-05-20 23:09 ` Brian Ford 0 siblings, 0 replies; 8+ messages in thread From: Brian Ford @ 2003-05-20 23:09 UTC (permalink / raw) To: gdb Sorry. Somehow this missed the list and went straight to David. On Tue, 20 May 2003, Brian Ford wrote: > On 20 May 2003, David Carlton wrote: > > > On Tue, 20 May 2003 17:05:26 -0500 (CDT), Brian Ford <ford@vss.fsi.com> said: > > > > > (gdb) p *pst > > > $1 = {next = 0x1052a018, filename = 0x1052a0e8 "../../gcc/gcc/libgcc2.c", > > > fullname = 0x0, objfile = 0x10148238, section_offsets = 0x1014e440, > > > textlow = 4922848, texthigh = 4922848, dependencies = 0x1052a118, > > > number_of_dependencies = 4, globals_offset = 1151, n_global_syms = 2, > > > statics_offset = 24280, n_static_syms = 21, symtab = 0x0, > > > read_symtab = 0x4f1170 <dbx_psymtab_to_symtab>, > > > read_symtab_private = 0x1052a100 "D\030\031", readin = 0 '\0'} > > > > Hmm. It doesn't look too strange to me. Are the libraries that GCC > > builds being compiled using your DWARF 2 in PE/COFF mechanisms? If > > not, is there any way you can think of that that would cause problems? > > > No, it must be a case of corruption as they are still in stabs. > > Here is my object's pst at dwarf2read.c:1354: > > (top-gdb) p *pst > $1 = {next = 0x1052a4e0, > filename = 0x105039d8 "../../../visual/vital/buf_init/bufs.c", > fullname = 0x0, objfile = 0x10148540, section_offsets = 0x1014e748, > textlow = 0, texthigh = 0, dependencies = 0x0, number_of_dependencies = > 0, > globals_offset = 0, n_global_syms = 42, statics_offset = 0, > n_static_syms = 420, symtab = 0x0, > read_symtab = 0x542d40 <dwarf2_psymtab_to_symtab>, > read_symtab_private = 0x10503a00 " ¸R\020", readin = 0 '\0'} > > The one that appears corrupt is *pst->next->next: > > (top-gdb) p *pst->next > $4 = {next = 0x1052a460, filename = 0x1052a528 > "../../gcc/gcc/gbl-ctors.h", > fullname = 0x0, objfile = 0x10148540, section_offsets = 0x1014e748, > textlow = 0, texthigh = 0, dependencies = 0x1052a560, > number_of_dependencies = 1, globals_offset = 0, n_global_syms = 0, > statics_offset = 0, n_static_syms = 0, symtab = 0x0, > read_symtab = 0x4f1170 <dbx_psymtab_to_symtab>, > read_symtab_private = 0x1052a548 "", readin = 0 '\0'} > (top-gdb) p *pst->next->next > $5 = {next = 0x1052a3d8, filename = 0x1052a4a8 "../../gcc/gcc/libgcc2.c", > fullname = 0x0, objfile = 0x10148540, section_offsets = 0x1014e748, > textlow = 0, texthigh = 0, dependencies = 0x1052a4d8, > number_of_dependencies = 1, globals_offset = 0, n_global_syms = 0, > statics_offset = 0, n_static_syms = 0, symtab = 0x0, > read_symtab = 0x4f1170 <dbx_psymtab_to_symtab>, > read_symtab_private = 0x1052a4c0 "", readin = 0 '\0'} > -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <vt2el2st5tj.fsf@zenia.red-bean.com>]
* Re: DWARF2 PE/COFF port and parsing ? [not found] <vt2el2st5tj.fsf@zenia.red-bean.com> @ 2003-05-21 21:11 ` Brian Ford 0 siblings, 0 replies; 8+ messages in thread From: Brian Ford @ 2003-05-21 21:11 UTC (permalink / raw) To: gdb On 21 May 2003, Jim Blandy wrote: > You may find the 'maint info psymtab' and 'maint info symtab' > functions helpful in debugging this kind of thing. The output > includes addresses for the objects it describes. > Thanks. The problem is, I crash as soon as I load the symbol file while looking up main. So, the command interface isn't very helpful. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ^ permalink raw reply [flat|nested] 8+ messages in thread
* DWARF2 PE/COFF port and parsing ? @ 2003-05-20 21:15 Brian Ford 2003-05-20 21:34 ` David Carlton 0 siblings, 1 reply; 8+ messages in thread From: Brian Ford @ 2003-05-20 21:15 UTC (permalink / raw) To: gdb I'm still slowly trying to add DWARF2 support for PE/COFF targets. I have the following problem that confuses me and I was hoping for some expert guidance about how to proceed. gdb's symbol table code is completely foreign to me. If I load an executable into gdb that contains one object file with DWARF2 information (all the rest stabs), I get a segfault here: 1431 if (!do_linear_search 1432 && (SYMBOL_LANGUAGE (*center) == language_java)) 1433 { 1434 do_linear_search = 1; 1435 } (gdb) p *center $1 = (struct partial_symbol *) 0x20 (gdb) bt #0 0x004479b8 in lookup_partial_symbol (pst=0x1052a0a0, name=0x44bf51 "main", linkage_name=0x0, global=1, domain=VAR_DOMAIN) at ../../gcc/gdb/symtab.c:1431 #1 0x004480b9 in find_main_psymtab () at ../../gcc/gdb/symtab.c:1608 #2 0x0041c11e in set_initial_language () at ../../gcc/gdb/symfile.c:1278 #3 0x0041bac0 in symbol_file_add_main (args=0x22ff1e "v9win/tap/vital.sym", from_tty=0) at ../../gcc/gdb/symfile.c:1017 #4 0x00417978 in do_captured_command (data=0x22fa90) at ../../gcc/gdb/top.c:521 #5 0x004178e1 in do_catch_errors (uiout=0x101240a0, data=0x22fa70) at ../../gcc/gdb/top.c:492 #6 0x004177a0 in catcher (func=0x4178d0 <do_catch_errors>, func_uiout=0x101240a0, func_args=0x22fa70, func_val=0x22fa6c, func_caught=0x22fa68, errstring=0x41798d "", mask=6) at ../../gcc/gdb/top.c:424 #7 0x0041793a in catch_errors (func=0x417960 <do_captured_command>, func_args=0x22fa90, errstring=0x41798d "", mask=6) at ../../gcc/gdb/top.c:504 #8 0x004179ca in catch_command_errors ( command=0x41baa0 <symbol_file_add_main>, arg=0x22ff1e "v9win/tap/vital.sym", from_tty=0, mask=6) at ../../gcc/gdb/top.c:541 #9 0x00401eeb in captured_main (data=0x22fda8) at ../../gcc/gdb/main.c:654 #10 0x004178e1 in do_catch_errors (uiout=0x5ef090, data=0x22fd60) at ../../gcc/gdb/top.c:492 #11 0x004177a0 in catcher (func=0x4178d0 <do_catch_errors>, func_uiout=0x5ef090, func_args=0x22fd60, func_val=0x22fd5c, func_caught=0x22fd58, errstring=0x401211 "", mask=6) at ../../gcc/gdb/top.c:424 #12 0x0041793a in catch_errors (func=0x401420 <captured_main>, func_args=0x22fda8, errstring=0x401211 "", mask=6) at ../../gcc/gdb/top.c:504 #13 0x00402331 in gdb_main (args=0x22fda8) at ../../gcc/gdb/main.c:813 #14 0x004010da in main (argc=2, argv=0x10101d08) at ../../gcc/gdb/gdb.c:35 #15 0x610068ea in _libuser32_a_iname () #16 0x61006b73 in _libuser32_a_iname () #17 0x005eca12 in cygwin_crt0 () #18 0x0040103c in mainCRTStartup () #19 0x77f1bbb5 in _libuser32_a_iname () The strange thing is that if I load the object file by itself, all is well (ie. info types runs to completion). Any pointers would be greatly appreciated. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: DWARF2 PE/COFF port and parsing ? 2003-05-20 21:15 Brian Ford @ 2003-05-20 21:34 ` David Carlton 2003-05-20 21:57 ` Brian Ford 0 siblings, 1 reply; 8+ messages in thread From: David Carlton @ 2003-05-20 21:34 UTC (permalink / raw) To: Brian Ford; +Cc: gdb On Tue, 20 May 2003 16:14:32 -0500 (CDT), Brian Ford <ford@vss.fsi.com> said: > I'm still slowly trying to add DWARF2 support for PE/COFF targets. I have > the following problem that confuses me and I was hoping for some expert > guidance about how to proceed. gdb's symbol table code is completely > foreign to me. > If I load an executable into gdb that contains one object file with DWARF2 > information (all the rest stabs), I get a segfault here: > 1431 if (!do_linear_search > 1432 && (SYMBOL_LANGUAGE (*center) == language_java)) > 1433 { > 1434 do_linear_search = 1; > 1435 } The above code really should be deleted from the function in question, but never mind that; at least it's being a useful canary in the coal mine. > (gdb) p *center > $1 = (struct partial_symbol *) 0x20 That's bad: 0x20 doesn't look like an address. So the partial symbol table in question is screwed up. Unfortunately, by the time you hit this bug, we've long since built the partial symbol tables. For an example of building a partial symbol table, see dwarf2read.c:dwarf2_build_psymtabs_hard. It gets created with start_psymtab_common, then some fields get set, then a function gets called (scan_partial_symbols, in this case) that eventually translates into a bunch of calls to add_psymbol_to_list to add the actual partial symbols, then the number of global and static symbols get set, then sort_pst_symbols gets called. From your symptoms, maybe the number of global and/or static symbols got set wrong (or not at all) somewhere. What does "p *pst" say? Unfortunately, the bug may have occurred when another psymtab was being generated: all the psymtabs within one objfile share one data structure, so an error when generating one psymtab may corrupt another psymtab's data. (Sigh. Partial symbol tables are a mess.) If this doesn't help, maybe you could give some more details about exactly how you've been tinkering with the readers. David Carlton carlton@math.stanford.edu ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: DWARF2 PE/COFF port and parsing ? 2003-05-20 21:34 ` David Carlton @ 2003-05-20 21:57 ` Brian Ford 2003-05-20 22:05 ` Brian Ford 2003-05-20 22:17 ` David Carlton 0 siblings, 2 replies; 8+ messages in thread From: Brian Ford @ 2003-05-20 21:57 UTC (permalink / raw) To: gdb Thanks for the Cc. I am not on the list. On 20 May 2003, David Carlton wrote: > On Tue, 20 May 2003 16:14:32 -0500 (CDT), Brian Ford <ford@vss.fsi.com> said: > > > I'm still slowly trying to add DWARF2 support for PE/COFF targets. I have > > the following problem that confuses me and I was hoping for some expert > > guidance about how to proceed. gdb's symbol table code is completely > > foreign to me. > > > If I load an executable into gdb that contains one object file with DWARF2 > > information (all the rest stabs), I get a segfault here: > > > 1431 if (!do_linear_search > > 1432 && (SYMBOL_LANGUAGE (*center) == language_java)) > > 1433 { > > 1434 do_linear_search = 1; > > 1435 } > > The above code really should be deleted from the function in question, > but never mind that; at least it's being a useful canary in the coal > mine. > > > (gdb) p *center > > $1 = (struct partial_symbol *) 0x20 > > That's bad: 0x20 doesn't look like an address. So the partial symbol > table in question is screwed up. Unfortunately, by the time you hit > this bug, we've long since built the partial symbol tables. > Yup. I know. > For an example of building a partial symbol table, see > dwarf2read.c:dwarf2_build_psymtabs_hard. It gets created with > start_psymtab_common, then some fields get set, then a function gets > called (scan_partial_symbols, in this case) that eventually translates > into a bunch of calls to add_psymbol_to_list to add the actual partial > symbols, then the number of global and static symbols get set, then > sort_pst_symbols gets called. From your symptoms, maybe the number of > global and/or static symbols got set wrong (or not at all) somewhere. > Thanks for the road map. That was a good portion of what I was looking for. I'll have to trace down the chain. Your assumption of what the problem is sounds pretty good to me. > What does "p *pst" say? Unfortunately, the bug may have occurred when > another psymtab was being generated: all the psymtabs within one > objfile share one data structure, so an error when generating one > psymtab may corrupt another psymtab's data. (Sigh. Partial symbol > tables are a mess.) > (gdb) p *pst Cannot access memory at address 0x0 (gdb) p pst $1 = (struct partial_symtab *) 0x0 > If this doesn't help, maybe you could give some more details about > exactly how you've been tinkering with the readers. > Actually, I haven't. The tinkering I have done is in binutils to get valid DWARF2 objects and let bfd know that PE/COFF can produce them. gdb is current cvs. I have more tinkering to go, but the objects and executables should be valid. libdwarf and dwarfdump have no trouble parsing them. Thanks for the help and let me know if you think of anything to add. I'll try to start the chase in the psymtab building now that I have a very fuzzy road map. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: DWARF2 PE/COFF port and parsing ? 2003-05-20 21:57 ` Brian Ford @ 2003-05-20 22:05 ` Brian Ford 2003-05-20 22:45 ` David Carlton 2003-05-20 22:17 ` David Carlton 1 sibling, 1 reply; 8+ messages in thread From: Brian Ford @ 2003-05-20 22:05 UTC (permalink / raw) To: gdb On Tue, 20 May 2003, Brian Ford wrote: > > What does "p *pst" say? Unfortunately, the bug may have occurred when > > another psymtab was being generated: all the psymtabs within one > > objfile share one data structure, so an error when generating one > > psymtab may corrupt another psymtab's data. (Sigh. Partial symbol > > tables are a mess.) > > > (gdb) p *pst > Cannot access memory at address 0x0 > (gdb) p pst > $1 = (struct partial_symtab *) 0x0 > Um, sorry. That obviously looks wrong because of optimization. Here is what it says without -O2: (gdb) p *pst $1 = {next = 0x1052a018, filename = 0x1052a0e8 "../../gcc/gcc/libgcc2.c", fullname = 0x0, objfile = 0x10148238, section_offsets = 0x1014e440, textlow = 4922848, texthigh = 4922848, dependencies = 0x1052a118, number_of_dependencies = 4, globals_offset = 1151, n_global_syms = 2, statics_offset = 24280, n_static_syms = 21, symtab = 0x0, read_symtab = 0x4f1170 <dbx_psymtab_to_symtab>, read_symtab_private = 0x1052a100 "D\030\031", readin = 0 '\0'} -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: DWARF2 PE/COFF port and parsing ? 2003-05-20 22:05 ` Brian Ford @ 2003-05-20 22:45 ` David Carlton 0 siblings, 0 replies; 8+ messages in thread From: David Carlton @ 2003-05-20 22:45 UTC (permalink / raw) To: Brian Ford; +Cc: gdb On Tue, 20 May 2003 17:05:26 -0500 (CDT), Brian Ford <ford@vss.fsi.com> said: > On Tue, 20 May 2003, Brian Ford wrote: >> > What does "p *pst" say? Unfortunately, the bug may have occurred when >> > another psymtab was being generated: all the psymtabs within one >> > objfile share one data structure, so an error when generating one >> > psymtab may corrupt another psymtab's data. (Sigh. Partial symbol >> > tables are a mess.) >> > >> (gdb) p *pst >> Cannot access memory at address 0x0 >> (gdb) p pst >> $1 = (struct partial_symtab *) 0x0 >> > Um, sorry. That obviously looks wrong because of optimization. Here is > what it says without -O2: > (gdb) p *pst > $1 = {next = 0x1052a018, filename = 0x1052a0e8 "../../gcc/gcc/libgcc2.c", > fullname = 0x0, objfile = 0x10148238, section_offsets = 0x1014e440, > textlow = 4922848, texthigh = 4922848, dependencies = 0x1052a118, > number_of_dependencies = 4, globals_offset = 1151, n_global_syms = 2, > statics_offset = 24280, n_static_syms = 21, symtab = 0x0, > read_symtab = 0x4f1170 <dbx_psymtab_to_symtab>, > read_symtab_private = 0x1052a100 "D\030\031", readin = 0 '\0'} Hmm. It doesn't look too strange to me. Are the libraries that GCC builds being compiled using your DWARF 2 in PE/COFF mechanisms? If not, is there any way you can think of that that would cause problems? David Carlton carlton@math.stanford.edu ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: DWARF2 PE/COFF port and parsing ? 2003-05-20 21:57 ` Brian Ford 2003-05-20 22:05 ` Brian Ford @ 2003-05-20 22:17 ` David Carlton 1 sibling, 0 replies; 8+ messages in thread From: David Carlton @ 2003-05-20 22:17 UTC (permalink / raw) To: Brian Ford; +Cc: gdb On Tue, 20 May 2003 16:56:52 -0500 (CDT), Brian Ford <ford@vss.fsi.com> said: >> What does "p *pst" say? > (gdb) p *pst > Cannot access memory at address 0x0 > (gdb) p pst > $1 = (struct partial_symtab *) 0x0 That's unfortunate; maybe the optimizer has already invalidated pst at that point? You could try finding an earlier place in the command where pst is still valid and have GDB print out the value of pst each time it hits that location (which will happen a lot), and then, when GDB crashes, look at the last value for pst and print out *((struct partial_sytmab *) <insert last value>) Maybe that will give a clue as to what's going on; maybe it won't. >> If this doesn't help, maybe you could give some more details about >> exactly how you've been tinkering with the readers. > Actually, I haven't. The tinkering I have done is in binutils to get > valid DWARF2 objects and let bfd know that PE/COFF can produce them. gdb > is current cvs. I have more tinkering to go, but the objects and > executables should be valid. libdwarf and dwarfdump have no trouble > parsing them. Weird. I'm pretty confused, but maybe following through the psymtab building will help. David Carlton carlton@math.stanford.edu ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-21 21:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.GSO.4.44.0305201745440.22269-100000@eos> 2003-05-20 23:09 ` DWARF2 PE/COFF port and parsing ? Brian Ford [not found] <vt2el2st5tj.fsf@zenia.red-bean.com> 2003-05-21 21:11 ` Brian Ford 2003-05-20 21:15 Brian Ford 2003-05-20 21:34 ` David Carlton 2003-05-20 21:57 ` Brian Ford 2003-05-20 22:05 ` Brian Ford 2003-05-20 22:45 ` David Carlton 2003-05-20 22:17 ` David Carlton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).