Re: [Tinycc-devel] Undefined symbol '__ashldi3'

[Michael Matz]

Hi,

On Wed, 13 Mar 2019, Andy Goth wrote:

> Thank you for all your help. I have succeeded in resolving the issue. As I
> stated in my first email, I am using gcc to compile tcc. gcc is indeed
> putting underscores at the beginning of symbol names and is using the PE
> object file format. To work around this, I patched the tcc4tcl build
> process to run objcopy on libtcc1.a to remove the underscores and convert
> the archive members to ELF. The patch is probably not of interest to anyone
> else here because it includes no changes to tcc itself.

Ah, newer TCCs always compile libtcc1 with TCC itself (except if using a 
non-default explicit make target), so this should be specific to the old 
TCC version used by tcc4tcl.  Cute hack^Wwork-around with objcopy :)


Ciao,
Michael.

> 
> See also: http://wiki.tcl.tk/tcc4tcl
> 
> On Wed, Mar 13, 2019, 08:33 Michael Matz <address@hidden> wrote:
> 
> > Hi,
> >
> > On Tue, 12 Mar 2019, Andy Goth wrote:
> >
> > > So there's the big clue. The code is asking for ashldi3 with two leading
> > > underscores, but the archive index contains ashldi3 with three leading
> > > underscores. Thus, the archive object libtcc1.o doesn't contain the
> > > requested symbol and therefore is not loaded.
> >
> > Well, so there's a mismatch in configuration between whatever compiled
> > your libtcc1.o and your TCC used as code generator, I think it's best to
> > resolve this instead of trying to make it work in presence of this
> > mismatch.
> >
> > > I read that on 32-bit (but not 64-bit) Windows, "cdecl" function names
> > > are prefixed by an underscore. (Also I see _tclStubs, which is a global
> > > variable, has an underscore prefix too.) There's a fair bit of code in
> > > tcc to address this, for example in pe_find_import(), but there's no
> > > analogue in tcc_load_alacarte().
> > >
> > > It seems odd adding PE-specific symbol mangling code to
> > > tcc_load_alacarte() which lives in tccelf.c. Instead, I feel it makes
> > > more sense for the PE-specific part of put_extern_sym2() to handle
> > > FUNC_CDECL when can_add_underscore is true.
> > >
> > > This... works? Kind of? When I try it, it indeed calls
> > > tcc_load_object_file() because ___ashldi3 now matches. But then it fails
> > > with an "invalid object file" error, since tcc_load_object_file() chokes
> > > on the object file not starting with the ELF header magic number. And it
> > > makes perfect sense that it would fail, since the object file is in PE
> > > format, not ELF.
> > >
> > > How is this expected to work? Is it wrong to put PE object files in an
> > > "ar" archive? That's how the makefile does it on all platforms, so
> > > clearly that's intended.
> >
> > TCC can only load ELF object files (and archives), also on Windows.
> > (Well, it can also load the export table of Windows PE DLLs).  So if you
> > want to load libtcc1.a it must be produced by a compiler producing ELF
> > files (on Windows it's probably easiest if it's produced by TCC).
> >
> > Maybe that's where your mismatch comes from?  That your libtcc1.o/a is
> > compiled by something else than the TCC you have?
> >
> >
> > Ciao,
> > Michael.
> >
> > >
> > > On Tue, Mar 12, 2019, 12:50 Louis Botha <address@hidden> wrote:
> > >
> > > > Hi Andy,
> > > >
> > > >
> > > >
> > > > I have a Windows application that loads libtcc1-32.a or libtcc1-64.a
> > > > dynamically, all I did was to call both with of these:
> > > >
> > > >
> > > >
> > > >        tcc_set_lib_path
> > > >
> > > >        tcc_add_library_path
> > > >
> > > >
> > > >
> > > > before calling tcc_compile_string (not sure if both of these are needed
> > > > but that’s what I did originally).
> > > >
> > > > The path that I passed to those functions has a sub-folder called lib
> > that
> > > > contains libtcc1-32.a and libtcc1-64.a,
> > > >
> > > >
> > > >
> > > > Not sure it’s that simple in tcc4tccl but hope that helps.
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Louis
> > > >
> > > >
> > > >
> > > > *From:* Tinycc-devel <tinycc-devel-bounces+lbotha=
> > > > address@hidden> *On Behalf Of *Andy Goth
> > > > *Sent:* Monday, March 11, 2019 9:28 PM
> > > > *To:* address@hidden
> > > > *Subject:* Re: [Tinycc-devel] Undefined symbol '__ashldi3'
> > > >
> > > >
> > > >
> > > > My application is a Tcl interpreter, so it doesn't directly link with
> > > > libtcc1.a and rather tries to dynamically load it. This is working fine
> > > > with 32-bit Linux but not Windows.
> > > >
> > > >
> > > >
> > > > In trying to force linking with libtcc1.a, I hit more problems. The
> > main
> > > > issue is that without "-Wl,-whole-archive", the linker sees no reason
> > to
> > > > include any part of libtcc1.a, since no part of the application uses
> > it.
> > > > Then when I do use "-Wl,-whole-archive", I get other link errors due to
> > > > other object files in libtcc1.a that I don't care about, stuff about
> > > > WinMain or whatever. Sorry, I didn't bother to take detailed notes on
> > that,
> > > > since I moved on to directly trying to pull in libtcc1.o and alloca86.o
> > > > since that's all I think I need. But while I did get them to link by
> > hand,
> > > > I couldn't figure out how to mechanize the required link command
> > within the
> > > > framework of the Tcl application build system, so I couldn't invoke the
> > > > rest of the build process needed to give the interpreter its virtual
> > > > filesystem.
> > > >
> > > >
> > > >
> > > > So I'm stepping back from that to ask how it's supposed to work for my
> > > > application to link to libtcc1.a rather than rely on tcc to dynamically
> > > > load libtcc1.a, which is what it's doing nicely on Linux already.
> > > >
> > > >
> > > >
> > > > Granted, this libtcc1.a dynamic loading might be bolted onto tcc by the
> > > > patches that come with tcc4tcl, so if anything I'm saying sounds alien
> > to
> > > > the design of tcc, let me know so I can bug the tcc4tcl author instead.
> > > >
> > > >
> > > >
> > > > I tried hard to use gdb to debug dynamic loading, but it's proving to
> > be a
> > > > nightmare in Windows. gdb is not showing me my arguments, it's
> > claiming all
> > > > functions are defined in some unrelated C++ header file, and I had to
> > find
> > > > and build debugbreak.c just to be able to Ctrl+C my process and get
> > back to
> > > > the gdb prompt. And stdout isn't working for me either. So I'm really
> > not
> > > > sure how to debug. Nevertheless, I do see that pe_add_runtime() is
> > being
> > > > called, which in turn tries and fails to load libtcc1.a using
> > > > tcc_add_dll(). I wish I could inspect the arguments being passed to
> > > > tcc_add_file_internal(), but gdb is not cooperating, despite me
> > compiling
> > > > everything with -ggdb3 and forgoing the strip stage of the Tcl build
> > > > process.
> > > >
> > > >
> > > >
> > > > On Fri, Mar 8, 2019, 08:04 Michael Matz <address@hidden> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Fri, 8 Mar 2019, Andy Goth wrote:
> > > >
> > > > > On Fri, Mar 8, 2019, 00:46 Andy Goth <address@hidden>
> > wrote:
> > > > >
> > > > > > With tcc4tcl 0.30 (tcc 0.9.26) compiled with MXE GCC 5.4.0, I get
> > the
> > > > > > following error:
> > > > > >
> > > > >
> > > > > I left out a critical detail. This is 32-bit Windows MXE GCC. I
> > haven't
> > > > > tried 64-bit Windows yet, but it works fine in both 32- and 64-bit
> > Linux.
> > > >
> > > > Yes, only 32bit code emits calls to this function, on both Windows and
> > > > Linux.  The function is defined in either libgcc.a or libtcc1.a which
> > > > TCC automatically should link against (either of them).  Somehow this
> > is
> > > > not happening, I can't say why, you'll have to figure it out.
> > > >
> > > > Alternatively, if there are reasons why you don't link against
> > libtcc1.a
> > > > or libgcc.a you will have to provide an implementation of this function
> > > > yourself, you could look into lib/libtcc1.c source for that.
> > > >
> > > > There are other helper functions that TCC might also generate calls for
> > > > in the i386 backend:
> > > >
> > > > __divdi3   long ret,x,y;  ret = x / y;
> > > > __udivdi3  ulong ret,x,y; ret = x / y;
> > > > __moddi3   long ret,x,y;  ret = x % y;
> > > > __umoddi3  ulong ret,x,y; ret = x % y;
> > > > __ashrdi3  long ret,x,y;  ret = x >> y;
> > > > __lshrdi3  ulong ret,x,y; ret = x >> y;
> > > > __floatundisf   ulong -> float
> > > > __floatundidf   ulong -> double
> > > > __floatundixf   ulong -> long double
> > > > __fixunssfdi    float -> ulong
> > > > __fixunsdfdi    double -> ulong
> > > > __fixunsxfdi    long double -> ulong
> > > > __fixsfdi       float -> long
> > > > __fixdfdi       double -> long
> > > > __fixxfdi       long double -> long
> > > >
> > > > So it's probably easier to just figure out why libtcc1.a isn't linked
> > > > automatically with your program.
> > > >
> > > >
> > > > Ciao,
> > > > Michael.
> > > >
> > > > _______________________________________________
> > > > Tinycc-devel mailing list
> > > > address@hidden
> > > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> > > >
> > > > _______________________________________________
> > > > Tinycc-devel mailing list
> > > > address@hidden
> > > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> > > >
> > > _______________________________________________
> > Tinycc-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> >
>