From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alagu Sankar To: gdb@sourceware.cygnus.com Subject: Re: Questions on GDB Date: Fri, 02 Jun 2000 14:20:00 -0000 Message-id: <38E7B8EC.E9B91072@realnetsi.com> References: <8B0BE50D6F9AD01185A300A0C92BF455088393EE@US01XCH01.Trimble.COM> X-SW-Source: 2000-06/msg00024.html Hello, I am using gdb 4.18 with wiggler for mpc8xx on a win nt hosted system. I am using cygwin tools and cross compiler for powerpc-eabi target. I am able to connect to the target but unable to modify the registers. When i try to set the processor for 860 my info registers command fails as following "read_bdm_registers : sr0 Invalid CPU register access attempt failed" I see people taking about 'ocd reg' command for modifying the special purpose. But this is not availabe in gdb 4.18. Is there a patch for it somewhere? Regards, Alagu Will Lentz wrote: > Hi Pete, > > For a remote PPC target (through rproxy), I use: > file xyz.elf > target remote ip.addr:port > load > run > > It's really cool that you ported the Macraigor DLL to Linux! I > think more people would use the Wiggler if your port was made > available :-). > > Will > > > -----Original Message----- > > From: Peter Reilley [ mailto:micrio@mv.com ] > > Sent: Thursday, June 01, 2000 2:24 PM > > To: gdb@sourceware.cygnus.com > > Subject: Questions on GDB > > > > > > I have a few questions on the operation of GDB with the Wiggler > > and a PowerPC target. > > > > I have ported the Macraigor DLL from MS Windows to Linux and > > am attempting to get GDB working. I can read and write registers > > and memory in the PPC target. I have a small test program that > > I compiled with GCC configured as a cross compiler for the PPC. > > I can use the "load" command and have the binary load properly > > in the target memory. I can use the "symbol-file" command to > > load the symbols. The "file" command will load the binary but > > it seems to have a base address in the host and not the target. > > The "run" and "step" commands do not seem to work. > > > > Anyway, what are the commands that you used to load and execute > > a binary in a target under Windows. The documentation that I found > > on the internet is conflicting. > > > > Thanks, > > Pete. > > > > > > > > > > >From alagu@realnetsi.com Fri Jun 02 14:24:00 2000 From: Alagu Sankar To: gdb@sourceware.cygnus.com Subject: wiggler with gdb-4.81 Date: Fri, 02 Jun 2000 14:24:00 -0000 Message-id: <3938254E.4D8A1A5D@realnetsi.com> X-SW-Source: 2000-06/msg00025.html Content-length: 541 I am using gdb 4.18 with wiggler for mpc8xx on a win nt hosted system. I am using cygwin tools and cross compiler for powerpc-eabi target. I am able to connect to the target but unable to modify the registers. When i try to set the processor for 860 my info registers command fails as following "read_bdm_registers : sr0 Invalid CPU register access attempt failed" I see people taking about 'ocd reg' command for modifying the special purpose. But this is not available in gdb 4.18. Is there a patch for it somewhere? Regards, Alagu >From jtc@redback.com Fri Jun 02 16:49:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: symbol table lookup performance Date: Fri, 02 Jun 2000 16:49:00 -0000 Message-id: <5m7lc7bq4z.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00026.html Content-length: 1920 My users are again complaining about poor performance of user defined functions, and again I've tracked it down to GDB's poor symbol table lookup performance. I've got to finish my open projects before even thinking about tackling symbol table optimization, but I did a quick check to see if there was any low hanging fruit. I profiled GDB, and determined that in running the script in question, some 67% of the time is spent in lookup_partial_symbol(), and that 27% of the time was spent in lookup_minimal_symbol(). I discovered that most of the calls to lookup_minimal_symbol() were from fixup_section(), as it attempts to dig out section information from the minimal symbols. But in this case most of the symbols being "fixed up" were types (used in casts in the script) and therefore had no section. Thus fixup_section() would call lookup_minimal_symbol() again and again for the same type symbol. I hacked in a change to fixup_symbol_section() that avoids calling fixup_section() if sym->aclass == LOC_TYPEDEF. After that change, the number of calls to lookup_minimal_symbol drops from 13753 to 2866; and the time drops from 135 to 29 seconds. Of course my users want much, much more than a 20% speed increase, but it will have to do for now. Index: symtab.c =================================================================== RCS file: /usr/rback/release/tools-src/gdb_ce_fe/gdb/gdb/symtab.c,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 symtab.c *** symtab.c 1999/07/15 18:46:07 1.1.1.2 --- symtab.c 2000/06/02 21:54:43 *************** *** 558,563 **** --- 564,572 ---- if (!sym) return NULL; + if (sym->aclass == LOC_TYPEDEF) + return sym; + if (SYMBOL_BFD_SECTION (sym)) return sym; Any thoughts on this change? It appears to work fine. --jtc -- J.T. Conklin RedBack Networks >From dan@cgsoftware.com Fri Jun 02 17:39:00 2000 From: "Daniel Berlin" To: , Subject: RE: symbol table lookup performance Date: Fri, 02 Jun 2000 17:39:00 -0000 Message-id: References: <5m7lc7bq4z.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00027.html Content-length: 2669 > > My users are again complaining about poor performance of user defined > functions, and again I've tracked it down to GDB's poor symbol table > lookup performance. I've got to finish my open projects before even > thinking about tackling symbol table optimization, but I did a quick > check to see if there was any low hanging fruit. I'm looking at this myself. > > I profiled GDB, and determined that in running the script in question, > some 67% of the time is spent in lookup_partial_symbol(), and that 27% > of the time was spent in lookup_minimal_symbol(). > > I discovered that most of the calls to lookup_minimal_symbol() were > from fixup_section(), as it attempts to dig out section information > from the minimal symbols. But in this case most of the symbols being > "fixed up" were types (used in casts in the script) and therefore had > no section. Thus fixup_section() would call lookup_minimal_symbol() > again and again for the same type symbol. > > I hacked in a change to fixup_symbol_section() that avoids calling > fixup_section() if sym->aclass == LOC_TYPEDEF. After that change, the > number of calls to lookup_minimal_symbol drops from 13753 to 2866; and > the time drops from 135 to 29 seconds. > > Of course my users want much, much more than a 20% speed increase, but > it will have to do for now. > > Index: symtab.c > =================================================================== > RCS file: /usr/rback/release/tools-src/gdb_ce_fe/gdb/gdb/symtab.c,v > retrieving revision 1.1.1.2 > diff -c -r1.1.1.2 symtab.c > *** symtab.c 1999/07/15 18:46:07 1.1.1.2 > --- symtab.c 2000/06/02 21:54:43 > *************** > *** 558,563 **** > --- 564,572 ---- > if (!sym) > return NULL; > > + if (sym->aclass == LOC_TYPEDEF) > + return sym; > + > if (SYMBOL_BFD_SECTION (sym)) > return sym; > > Any thoughts on this change? It appears to work fine. > > --jtc > Looks fine to me. Also, what type of debug info is this on? It makes a huge difference. If it's DWARF2, my "waiting for approval" changes i sent a few days ago will reduce the total number of symbols dramatically, and thus, speed up the symbol table stuff because it'll have to deal with less symbols. If it's not too much trouble, could you tell me if lookup_partial_symbol is trying to look up the same 100 or so symbols, again and again? I would imagine at a given point in time, their is a set of symbols you'll be using. If it's trying to look up the same symbols, again and again, i'll implement a simple LRU cache for the past 100 looked up symbols. --Dan