Re: Questions on GDB

[Alagu Sankar <alagu@realnetsi.com>]

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 <alagu@realnetsi.com>
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" <dan@cgsoftware.com>
To: <jtc@redback.com>, <gdb@sourceware.cygnus.com>
Subject: RE: symbol table lookup performance
Date: Fri, 02 Jun 2000 17:39:00 -0000
Message-id: <BAEMJNPFHMFPEFAGBKKAEEJACEAA.dan@cgsoftware.com>
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