[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Feature requests and bug report
Re: [Tinycc-devel] Feature requests and bug report
Mon, 16 Feb 2009 17:07:38 +0100
Thunderbird 184.108.40.206 (Windows/20070221)
Arlen Keshabyan wrote:
My name is Arlen. I'm a programmer from Russia, so I'm sorry for my
bad English in advance.
First, let me thank you all (to whom it concerns) for TCC, for the
little precious Perl among the open source projects. Honestly, I've
used it as a scripting engine for my project. It shows great speed
results, it's easy and flexible to use. It exactly matches my
conceptions of a tool like TCC. While using it for awhile, I've
noticed some shortcomings. The first one is critical. It's about a
structure alignment. Consider the following code:
long long _size;
GCC tells me that this structure aligned by 8 bytes because 'long
long' type's size is 8 bytes. So, GCC used the longest type's size for
the structure alignment. Well, TCC aligned the same structure by 4
bytes. Because of this, this structure cannot be used for passing data
between my application and the TCC compiled code. The _size structure
member is inaccessible due to its different addresses (a shift from
the beginning of the structure) in TCC and GCC. So, I think TCC has to
align the structure by 8 bytes too, like GCC does it.
I have committed a fix for this:
The second thing is about runtime behavior. If I include 'tcc.c' file
into my application with LIBTCC defined then compilation goes OK, but
an error comes out while runtime. The library requests the 'libtcc1.a'
file to be somewhere around. I do not want the standard c-runtime
'libtcc1' to be included in libtcc and I want to provide my own
runtime library by adding my symbols or using shared libraries. Can
you provide a way to choose whether to load libtcc1 library runtime or
libtcc1.a is not "the standard c-runtime" but tcc specific compiler
support for long long arithmetics (mostly). If you don't need
that you can set the s->nostdlib flag or just comment out the line
where it is loaded.
That said, maybe libtcc could have a more general function like
which could also replace tcc_enable_debug() and tcc_set_warning().
Just currently there isn't something like that.
The third one is a feature request. Can you provide a way to set a
callback function to process pragmas in a source code while parsing
it. For instance, a function called 'tcc_set_pragma_callback'. This
function is supposed to get a single string parameter that is a string
right after the pragma directive. And this callback function is
supposed to return an integer value that tells a parser to do
something or not to. This way we can extend functionality a bit. For
#pragma shared(user32.dll, kernel32.dll, gdi32.dll, "C:/myfolder/myshared.dll")
This way I can add some libraries with 'tcc_add_library' function
requested in a source code. Or
I can tell a parser to skip the rest of a source code file by
returning a special value from my callback when it meets '#pragma
once' directive second time in the same file.
Anyway, a parser is supposed to call pragma callback function when it
meets an unknown pragma directive and I'm supposed to tell it what to
do – ignore the directive, ignore the whole file, stop parsing issuing
an error or do something else.
Well, you can push any new features on our "mob" branch anytime:
git push ssh://address@hidden/srv/git/tinycc.git my-feature-xyz:mob
It's otherwise hard to see whether it's useful and still simple (tiny)
enough that we want it for everyone ;)
The fourth thing is about shared libraries. When I use tcc_add_library
function to load an executable file with exported functions then the
function fails to load it until you provide a .def file for the
executable. As far as I know it only understands .dll, .def and .a
file extensions. Right?
TCC-PE loads only .def and .a. I know the gnu linker can load .dll
and maybe .exe. It would be possible for TCC in theory, basically
by merging tiny_impdef.c into tccpe.c. The advantage with .def files
is that it works for dll's that aren't present on the host-system.
If yes, can you do something to let load an
executable file as a shared library? As far as I know it's not so hard
to retrieve a list of exported functions from a shared library or
You cannot load exe's as "shared library" because there can be only
one exe-module in a process and it is already loaded by the OS.
If you want to load symbols at runtime from the exe where libtcc
is compiled in, then you could modify tccpe.c:resolve_sym such that
it tries to load any unknown symbols from the main module:
addr = GetProcAddress(GetModuleHandle(NULL), symbol);
Also "tcc_add_symbol()" can be used to make symbols known to libtcc.
Telling the truth, TCC is almost the most amazing thing I've ever seen and used.
Thank you ever so much for this great experience.
I'm impatient to see your C++ additions, since using simple classes,
'new' and 'delete' operators, and a simple string object are the great
additions to TCC.
C++? What's that? ;)
IIRC I've seen string objects, in some project derived from TinyCC,