tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] wish: ability to override pe dynamic linker


From: egodust
Subject: [Tinycc-devel] wish: ability to override pe dynamic linker
Date: Mon, 28 Apr 2008 12:13:03 +0100

Heyas,

I am using multiple states to compile sources into different memory
binaries (like DLLs), there have been problems and I have hit upon
another one, redundant DEF file parsing.

When tcc_new() is called, my code finds all DEFs and uses
tcc_add_library(), like this:

tcc=tcc_new()
for def in libdir:
    tcc_add_library(tcc, def)

With this, the user doesn't need to specific -l linker options and the
dynamic linker
will look at all DLL info that it knows about.

I am using:

advapi32.def, comdlg32.def, gdi32.def, kernel32.def, msvcrt.def,
ole32.def, shell32.def, shlwapi.def, user32.def, ws2_32.def

In total there are 4334 function names -- this information rarely
changes and is parsed from disk with each tcc_new()!

I thought of various ways of changing libtcc, including adding a
TCCRuntime* structure which would contained shared information (or
maybe even a global? ugh).

Instead, what I really want is to manage the linker stuff outside of
libtcc, for this, the following API addition is needed:

int tcc_override_pelinker(TCCState *, prototype)

This function will setup TCCState* so that tccpe.c/resolve_sym() does
not nothing but call
the function pointer, like this:

void * my_linker(TCCState * tcc, char * symbol, ??)
{
   // return symbol, void * must be valid as long as tcc is loaded.
   // if NULL is returned, normal linker operations will take place
}

With this change, I don't need to call tcc_add_library() to parse DEFs
and that information
within TCCState* won't exist multiple times.

My own code will parse the DEF files once at startup (and watch for
new changes... )
and then use its own DLL->name resolver, etc.. So how about it? :)

I also thought about adding a new API layer, i.e. libtccadv (advanced)
which contains
such APIs, that aren't recommended for most uses...

Kind Regards,
Sam K




reply via email to

[Prev in Thread] Current Thread [Next in Thread]