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 <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
