public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
* [Linux-ia64] ia64 toolchain problem
@ 2000-07-29 17:36 H . J . Lu
  0 siblings, 0 replies; only message in thread
From: H . J . Lu @ 2000-07-29 17:36 UTC (permalink / raw)
  To: linux-ia64

On Wed, Jul 26, 2000 at 05:02:27PM -0700, Jim Wilson wrote:
> I am aware of your messages on this subject to the FSF gcc mailing lists.
> However, none of your messages actually report any bugs.  You just claim
> that bugs exist and propose solutions for them.  Your proposed solutions
> involve a redesign of gcc, are highly controversial, and very unlikely to be
> adopted anytime soon.  Thus I am in a position where I can't fix anything
> because I don't have anything to work with.
> 
> As I understand it, glibc needs to know about frame_object which is a gcc
> internal variable.  The gcc hackers didn't know about this until you pointed
> it out.  frame_object had to be changed in gcc to support the Intel defined
> IA-64 exception handling model.  Thus glibc will have to be changed to match
> the gcc changes.  I see nothing in gcc to fix.  Since I'm not doing glibc

glibc is not the only place where frame_object is used. Is collect2
used on ia64? If yes, it has the same problem as glibc, which is what
my runtime.h proposal is trying to fix. My point is gcc should define
a stable ABI for those functions used outside of the compiler itself.
In this case, they are glibc and collect2. glibc and collect2 should
know anything about the internals of those functions. That is why I
made frame_object opaque.


H.J.



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-07-29 17:36 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-07-29 17:36 [Linux-ia64] ia64 toolchain problem H . J . Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox