Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Linus Torvalds <torvalds at transmeta dot com>]

Is there something really wrong with just sidestepping this issue
altogether with the following simple rule:

 - libgcc is always statically linked inside the object file that needs
   it (be it a binary or a shared library)

Yes. It will result in code duplication. Is that a huge problem? libgcc
is supposed to be small or non-existent anyway. I know it's bloated at
least right now - but looking at the x86 libgcc I have at least some of
the bloatedness seems to be due to bad coding and bad interfaces.

Wouldn't it be nicer to work on making the thing smaller instead, and
making people happier about just linking it statically? Make it be a
small thing that is hidden away inside gcc's own files, rather than
something that has to care about the shared library scheme of the
particular target architecture..

(Ugh. I looked at __negdi2 on x86. Not pretty. It looks like it should
be

	#ifdef _not_fastcall
		movl 4(%esp),%eax
		movl 8(%esp),%edx
	#endif
		notl %eax
		notl %edx
		addl $1,%eax
		adcl $0,%edx
		ret

instead of the current horror).  That's a whopping 20 bytes or so, which
is probably a lot less than the silly dynamic linking overhead would be
anyway, so "binary size" is not a very good argument for trying to make
this a .so.

Yes, some of them are larger. Not many. And maybe those larger ones
could be standardized well enough that they can be exported entirely
outside gcc and there would be that much less coupling between gcc and
glibc again..

			Linus