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

[RoboTux]

Le jeudi 22 avril 2010 23:28:02, grischka a écrit :
> 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_implem
> >entation
> 
> 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.

If gcc doesn't support that, then I guess there is no problem not supporting 
it in tinycc.
> 
> 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.
So set/longjmp uses the libc unwind model ? I thought it was more like a back 
up of registers in an array provided by the application (either an array on 
stack, or in static data) which can be done entirely in the glibc. And the 
following thread:

http://sourceware.org/ml/libc-alpha/1999-08/msg00037.html

makes me think indeed the set/longjmp functions aren't related to the unwind 
model.
> 
> 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.
I can't promise anything on this. My priority is to make tinycc work for 
static compilation. As tinycc doesn't support __try/__catch instrinsics, a 
dummy backend will be perfectly right for this purpose. But if set/longjmp 
doesn't work out of the box, I'll look later what's not working but it will 
certainly take more time.

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

Might not in that case. It only works for dynamic linking. I'll take a look 
this WE to extands this mechanism to static compilation as well. It shouldn't 
be too long. By the way, commit 7fa712e moved (and thus duplicated) the 
tcc_add_library(s1, "c"); inside the #ifdef statement ? Can I take advantage 
of the patch I'm gonna do to move it back just after the if (except if there 
is a reason to let it there which I might not see) ? The corresponding code 
is:

    if (!s1->nostdlib) {
#ifdef CONFIG_USE_LIBGCC
        tcc_add_library(s1, "c");
        tcc_add_file(s1, CONFIG_SYSROOT "/lib/libgcc_s.so.1");
#else
        char buf[1024];
        tcc_add_library(s1, "c");
        snprintf(buf, sizeof(buf), "%s/%s", s1->tcc_lib_path, "libtcc1.a");
        tcc_add_file(s1, buf);
#endif
    }
> 
> --- grischka

Best regards,

Thomas Preud'homme

signature.asc
Description: This is a digitally signed message part.