This is the mail archive of the
mailing list for the Archer project.
- 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: <firstname.lastname@example.org>
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...
Thiago Jung Bauermann
IBM Linux Technology Center