This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Tasks
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Mon, 28 Jul 2008 16:36:14 -0300
- Subject: Re: Tasks
- References: <m363qtg0ey.fsf@fleche.redhat.com>
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