Re: RFA: ia64 portion of libunwind patch

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> 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