This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: ia64 portion of libunwind patch
>>>>> On Sat, 8 Nov 2003 17:34:21 -0800, Marcel Moolenaar <marcel@xcllnt.net> said:
Marcel> On Fri, Nov 07, 2003 at 03:12:29PM -0800, David Mosberger wrote:
>> >>>>> On Fri, 07 Nov 2003 18:01:40 -0500, Andrew Cagney <ac131313@redhat.com> said:
Andrew> Is fetching the table elements via a function, rather than a
Andrew> direct access, really that significant an overhead?
>> Is allocating a scratch buffer in gdb really such a big issue?
>> It's very late for proposing libunwind API changes.
Marcel> I think it's very early to have it nailed down.
No, the static code part of libunwind is not really open to
non-backwards-compatible changes anymore. Things are slightly
different for the dynamic code support, but the static part has too
many users already for making code-breaking changes. Also,
backwards-compatible changes are of course much easier to add.
Marcel> Despite ones efforts to create a clean system, there are
Marcel> always assumptions underlying the code, including the API. I
Marcel> think it's in the best interest of libunwind if the
Marcel> developers (yes, you David :-) remain sensitive and open
Marcel> minded about the how well libunwind interfaces with or
Marcel> integrates into code that has a need for unwinding.
It's not a good idea to make broad conclusions based on one particular
issue. In this case, the issue appears to be entirely theoretical
(nobody has produced any numbers showing that, in a realistic
scenario, the current scheme makes, say, gdb startup X% slower, with X
being some large number). Unless somebody produces such numbers,
I'm certainly not going to change the API in a non-backwards-compatible
fashion.
Perhaps we can find a backwards-compatible way of doing this, in which
case it's _much_ easier to add the feature.
Also, please keep in mind that libunwind is an open-source project.
If you don't like something, or think a feature is missing, submit a
clean patch.
--david