ok, "other" Win64 / Linux x86-64 glue options...
BGB / cr88192
"unstable transfer thunks", which could benefit function pointers, but are
not otherwise desirable.
as noted, this was the idea from the prior thread of making function
pointers which auto-detect the caller and hash the results.
not doing anything of the sort, but this is sort of a cop-out.
annotating DLLs with additional metadata, but IMO this idea sucks.
"synthetic" DLLs (this would be either a real or stand-in DLL, whose sole
purpose is to provide glue code). in this case, likely the code would exist
in a meta-form (either a C-header like form, or a collection of keys for the
metadata database), and the "DLL" would likely be dynamically generated when
"loaded"...
advantage: this approach need not fundamentally change the conceptual DLL
mechanism, and would work with stock MSVC-produced DLLs, but would not
handle a few cases:
vararg functions, va_list. note that function pointers would be "use at your
own risk".
the cost then is this:
likely, this would create a "thick" wall between native Linux land, and
between synthetic Win64 land, meaning that many APIs would likely need to be
partially (or largely) wrapped;
similarly, it is likely that the interfaces would have to be manually
composed (likely as a special header declaring any relevant types and
any/all exported functions).
however, even as such, this is likely to be the most "stable" option at
present.
likely I will need to use newlib or some other C library (actually, I have
been faced with this issue for a while...).
this would be used in place of the standard C library (such as MSVCRT or
glibc).
newlib gives my worry by referring to 'configure' (where for me,
configure==the devil...).
I have no idea how much work it would take to build on MSVC and friends, and
GPL may be a deal-breaker (if used, have not yet checked).
I guess BSD and MSVC-friendly Makefiles would be asking too much...
unrelated:
I have just recently ended up using my C compiler for a piece of
statically-compiled code (probably the first time this has been done, since
I mostly use it for dynamic compilation...). I did linking with MSVC's
'link' tool, but had to manually supply the C runtime, since my compiler
does not insert linker commands into the produced COFF files.
however, at least with my small test app, it worked and produced sane
output.
I may work on making it suck less...
I may well add SysV support, so that it will be able to use both Win64 and
SysV (possibly at the same time...). this could be useful if I start taking
Linux x86-64 more seriously...
note that, even with my current level of "teh such" with Linux x86-64
support, for the "common basic case" (AKA: direct calls), in the past at
least it worked acceptably, mostly all of this is just about the endless
"edge cases" that would prevent something like this from "shining".
after all, basic hackish direct-mashalling still covers maybe 85-90% of the
function calls...
or such...
BGB / cr88192
"BGB / cr88192" <cr8...@hotmail.com> wrote in message
news:h9hp61$ml4$1...@news.albasani.net...
> so, here is what options I have:
>
> "unstable transfer thunks", which could benefit function pointers, but are
> not otherwise desirable.
> as noted, this was the idea from the prior thread of making function
> pointers which auto-detect the caller and hash the results.
>
> not doing anything of the sort, but this is sort of a cop-out.
>
> annotating DLLs with additional metadata, but IMO this idea sucks.
>
I have just given in now and added SysV/AMD64 support to my compiler, and
will probably use this on Linux.
granted, it is not exactly tested, and the performance will probably suck...
however, I did put on my own little prologues, which are related to
exception handling as my framework doesn't currently support DWARF...
granted, it is possible to select calling convention via modifiers:
__win64 and __amd64.
however, there is an added risk, as presently both calling conventions will
use the same function names, meaning that there is a high risk of clashing
if not used carefully.
however, as is, my assembler emits COFF and GOT is generally unsupported,
where these issues would likely need to be addressed for "native" Linux
static compilation (for dynamic compilation and linking, it works though).
I am left thinking that both my compiler and assembler will need some sort
of 'target' option (as-is, it is informal, and options default mostly to
whatever the compiler is running on...).
I am currently thinking like this: 'cpu-os'.
so, for example, "x86-win32", "x86-linux", "x64-win64", ...
I may pass this into the assembler via a special command:
[arch x64.win64]
which would set up various options, such as the default assembler output
format, ...
it would also set up things like whether the compiler tries to use PIC and
the GOT, ...
or such...