This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Using values to handle unwinding
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb at sourceware dot org, Mark Kettenis <kettenis at gnu dot org>, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Fri, 4 Apr 2008 10:37:10 -0700
- Subject: Re: [RFC] Using values to handle unwinding
- References: <20071017160350.GA26804@caradoc.them.org> <20080331220500.GA21611@caradoc.them.org>
I read the first patch (register values) pretty carefully, the second
one (frame unwinding using struct value & using this_frame instead of
next_frame) as carefully as I could, and skimed the other few patches.
Overall, it looks pretty nice. I think it would be very valuable if
others took the time to look at them, I had to spend a lot of time
to understand them, and even now I'm sure there are things I missed.
> I'd love comments on the patches, the overall approach, and how to
> proceed. Ideally, we check this in (breaking many targets), update
> each target completely as someone needs that target, and make sure all
> targets are updated by the next release of GDB. I personally use
> amd64, i386, arm, mips, m68k, and powerpc; so I'm pretty likely to
> update all of those (mechanically). I'll do the laggards before the
> next release too, but not right this minute. I would appreciate
> assistance with other targets :-)
You said "mechanically" - does it mean you are not able to test some
of the targets you listed?
I can help (including testing) with: hppa, ia64, sparc and powerpc (aix).
I would prefer if you took care of mips if you're able to test that.
In terms of other architectures that no one volunteers to convert, we
can split them among ourselves, and perform mechanical conversions.
We can use a second pair of eyes as our means of testing...
In terms of how to proceed, I don't mind if we temporarily break