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.
See also: http://wiki.tcl.tk/tcc4tcl On Wed, Mar 13, 2019, 08:33 Michael Matz <matz....@frakked.de> 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 <lbo...@nextivityinc.com> 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= > > > nextivityinc....@nongnu.org> *On Behalf Of *Andy Goth > > > *Sent:* Monday, March 11, 2019 9:28 PM > > > *To:* tinycc-devel@nongnu.org > > > *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 <matz....@frakked.de> wrote: > > > > > > Hi, > > > > > > On Fri, 8 Mar 2019, Andy Goth wrote: > > > > > > > On Fri, Mar 8, 2019, 00:46 Andy Goth <andrew.m.g...@gmail.com> > 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 > > > Tinycc-devel@nongnu.org > > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > > > > _______________________________________________ > > > Tinycc-devel mailing list > > > Tinycc-devel@nongnu.org > > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
