This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tasks


On Fri, 2008-07-25 at 14:43 -0600, Tom Tromey wrote:
> * Pretty-printing.  My plan here has been:
>   - Merge in the existing python work
>   - Make it possible to associate a 'struct type' with a given Python
>     object, in the non-MI case (the MI case is already in
>     there... FWIW we'd want to use the same Python objects to handle
>     both cases).
>   - Update 'print' to use this object if it exists
>   - Add 'print/r' (r == 'raw') to bypass the pretty-printer
>   - Write a bunch of pretty-printers for libstdc++.  There are some
>     good examples to start from (some on the wiki)
> 
>   So, for estimation we need to look at the size of some of these
>   parts, and also whether anything is missing.

Do you want to work on the pretty-printing? I know you've been thinking
about it already, and may have something baked. If not, I can work on
it, since I'm already doing python work in the other git branch. :-)

> * Scalability and shared libraries.  Profile some examples.  Figure
>   out what is wrong.  Jan has some information here.

One thing that is specific to powerpc that I'd like to have fixed is
PTRACE_GETREGS and PTRACE_SETREGS. They're currently buggy, so GDB on
Power uses PTRACE_PEEKUSR and PTRACE_POKEUSR which is slower. GDB on
Intel uses GETREGS and SETREGS.

I didn't do any measurements, but Daniel says it makes a difference and
I tend to believe him. :-)

So I'll see if I can get the attention of some kernel folks here to work
on it, or else have a try myself.

> * GCC changes.  I think the task list here should come from the above.
>   But, once we have that list of dependencies it would be worth making
>   another pass through GCC bugzilla to see what we are missing.  So,
>   we can leave this one for a bit.

This is not really GCC (I think it can be done in the linker): word on
the street is that for C++ programs, GCC generates a lot of duplicate
debuginfo, especially for header files. DWARF has mechanisms to avoid
such duplication. I'd like to investigate more about this and see what
can be done...
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]