This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix unwinding through SA_ONSTACK signal frames on IA-64

Hi Jim,

>>>>> On 18 Dec 2003 22:51:21 -0800, Jim Wilson <> said:

  Jim> There is the question of whether libunwind should be a separate
  Jim> GNU project, or be merged into GCC.  libunwind is useful in
  Jim> other projects, such as gdb, so it isn't clear that inside gcc
  Jim> is the best place for it.  It would be useful to build a
  Jim> libunwind enabled gdb even if you aren't using gcc as your
  Jim> compiler.  Maybe it makes sense to put it in glibc?

Initially, I also thought that libunwind could be part of glibc.  I'm
certainly not opposed to that, but in the past, Uli said that glibc is
too big already and that he doesn't want to add new interfaces (I'm
paraphrasing here...).  I can relate to that and for that reason, I
created libunwind as a separate library.  From my perspective, keeping
it a separate library is fine with me.

  Jim> However, it isn't clear if you want to go through this
  Jim> assignment process.  I suspect you don't.

_If_ that is the preferred route, I'd be willing to put in the effort.
But like you say, it's not an easy process.

  Jim> At the moment, we have a compromise, if libunwind is installed
  Jim> on the system, then gcc automatically uses it instead of the
  Jim> builtin unwinder on the assumption that libunwind is always
  Jim> better if you have it.

Yes, and it's a model that I'm comfortable with.  My concern is
whether Uli, Jakub and Rich (as important glibc/gcc contributors and
as Red Hat employees) are OK with it.  If they are not and Red Hat
ended up not shipping with a libunwind-enabled GCC in the foreseeable
future, that would clearly be a concern to me.  Especially now that
GDB has libunwind support and that a Java JVM vendor has started to
use the libunwind-interface to enable unwinding across
dynamically-generated code.  Also, I'm fairly certainly that Debian
will be enabling libunwind in GCC and I think the same may be true for
SuSE.  Similarly, the Intel compiler is also likely to switch to
libunwind in the not too distant future.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]