Hi Andy,

I stepped into my code and followed the same path as you to where __divdi3 etc. 
is searched, but in my case it is found because libtcc1-32.a (which I got here: 
 http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win32-bin.zip) 
contains the version with 2 underscores:

[cid:image001.jpg@01D4D92F.879C8860]

Best regards,
Louis


From: Tinycc-devel <tinycc-devel-bounces+lbotha=nextivityinc....@nongnu.org> On 
Behalf Of Andy Goth
Sent: Tuesday, March 12, 2019 7:18 PM
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Undefined symbol '__ashldi3'

(Sorry for top-posting. I'm forced to use Gmail on my phone.)

I've made progress with debugging and now have good stdout and intermittent 
gdb, by which I mean I can see locals and source and line numbers and do all 
that debug stuff like stepping and breakpoints, but then it will randomly 
decide to spew errors every time I touch the keyboard or mouse, making it 
uncontrollable. At this point I'm mostly just printing to stdout. Though I got 
much better stability by redirecting the program's stdin from a file.

I confirmed that libtcc1.a is being found and read by tcc_load_archive() which 
calls tcc_load_alacarte() on the archive member called "/". This then iterates 
through the archive symbol index, calling find_elf_sym() on everything, which 
I'm printing out:

___divddi3
___moddi3
___udivdi3

And so on. However, find_elf_sym() returns 0 for everything, so 
tcc_load_alacarte() never goes on to call tcc_load_object_file() to load the 
actual object file archive member.

Prior to tcc_load_archive() being called, I see add_elf_sym() being called with 
name="__ashldi3" and sh_num=SHN_UNDEF in preparation to load said symbol from 
wherever.

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.

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.

On Tue, Mar 12, 2019, 12:50 Louis Botha 
<lbo...@nextivityinc.com<mailto: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<mailto:nextivityinc....@nongnu.org>>
 On Behalf Of Andy Goth
Sent: Monday, March 11, 2019 9:28 PM
To: tinycc-devel@nongnu.org<mailto: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<mailto: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<mailto: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<mailto:Tinycc-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org<mailto: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

Reply via email to