tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Missing symbol when compiling in -static


From: grischka
Subject: Re: [Tinycc-devel] Missing symbol when compiling in -static
Date: Thu, 22 Apr 2010 23:28:02 +0200
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

RoboTux wrote:
It does not strictly depends on gcc, although it has obviously been thought with gcc in mind. It depends on low level routine for exception handling. I made a few search and I found is that libgcc_eh.a provides exception handling for all languages handled by gcc. Exception handling needs to unwind functions and the way it is done implied a specific stack layout. And only the compiler knows this stack layout so mostly all the exception handling is done in the glibc but the compiler has to provides a few function for low level things.

Wikipedia explains how exception handling impact the compiler and the stack:

http://en.wikipedia.org/wiki/Exception_handling#Exception_handling_implementation

Well, we have unwind support in tcc for windows 64bit.  Indeed it's defined
for the platform (not for the compiler) and basically exports some extra
data with entries for each compiled function.

As to gnu/linux I don't think that gcc supports some such as __try/__catch
intrinsics for C, and tcc doesn't do that either.

And without that the only way I see for tcc-compiled code to actively
participate in EH (beyond crashing) is calling the set/longjmp library
functions in libc, which means whatever tcc or gcc do they need to
comply with the unwind model used in libc.

Anyway, I'm fine with whatever solution if it works.  (If by the way
we can get a LLVM backend, the better ;) ) Of course set/longjmp would
be cool to have because tcc itself uses them (from error(...)) and we
want tcc to be able to compile itself, as always.

Also, someone already gave us a configure switch "--with-libgcc"
(-> CONFIG_USE_LIBGCC), which might or might not be useful.

--- grischka

On the other hand, provide dummy functions is
perfectly possible and doesn't introduce regression, even if the
functions aren't functional. On the contrary, they improve usability of
the software since it would allow many programs, which don't use the 4
undefined symbols neither directly, nor indirectly, to be compiled
statically with tinycc.

Thus, I'd like to commit dummy functions which anyone can then transform
in fully functional ones.
I guess to be "fully functional" this could easily mean several versions,
such as one for each gcc version that gnu/linux systems are compiled with.
I don't think these fonction evolves with gcc version. It's more related to the glibc than to gcc. The glibc provides exception handling but this mechanism requires some compiler support. Thus, I think it's the glibc which defines the API. I'll take a look to other compiler to see how they handle that case. Maybe llvm has an implementation we could reuse because its licence seems LGPL compatible. The llvm website summarize the llvm licence like this:

- You can freely distribute LLVM.
- You must retain the copyright notice if you redistribute LLVM.
- Binaries derived from LLVM must reproduce the copyright notice (e.g. in an included readme file).
- You can't use our names to promote your LLVM derived products.
There's no warranty on LLVM at all.

Or, as I previously said, we could implement dummy function and print a warning when static compiling that exception handling won't be supported.
Well, maybe I just don't understand.  Can we make "tcc -static" work with
libgcc_eh.a, say somewhat easily?
Before what I learned recently about this I would have said :

Yes I think so. The only technical problem is to find where it is stored: libgcc_eh.a is in /usr/lib/gcc/<arch>gcc-<version>. But that needs anyone which want to use tinycc must also have gcc installed. At least if we follow that way we should provides a way to disable tcc static compilation in the configure.

But now I'm really not sure it would work. If it's provided by gcc then there is a good chance that it's really compiler-dependant. Except if code compiled by tcc and gcc looks the same, I don't think we could link against libgcc_eh.a It seems to me the only solution is to implement in some way the function on the tcc side.
--- grischka

Thomas Preud'homme
Hope I'm clear and I'm not confused myself.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]