Dynamically loading a static C library (compiler suggestion?)

[cr88192]

They will do for now. But I'm not satisfied with this situation, thank
you.

Programming-wise, I think manufacturer is not very competent. I believe
that manufacturer can produce hardware and software that _works_ for a
price that I'm happy with, but I don't trust them in anything that's
related to programming. I use their library because it provides interface
to their hardware, but I'm not very fond of it.
I'll look at them, thanks.

No, my microcontroller doesn't have an emulation program. Besides,
emulation won't buy me much compared to real debugging. I can use DOS
emulation, but it's of little use plus it's not integrated into IDE.

Debugging through a serial port is also not available, as far as I know.
This is what I wanted to accomplish with Forth.

As far as I know it's OMF object file format. Is OMF loading hard? Who did
it?

loading is not hard, but linking with the running app is a little harder,
due to the amazing forsight of most of the folks writing compilers and
linkers and other tools...

sure, it is not impossible, but there are certainly easier things to do...


actually, I didn't think of it in the other thread, but it may be possible
to make this a lot easier, since you know the specific lib up front, you can
figure out what all external dependencies it has, and possibly make a table
mapping any symbols it needs to appropriate pointers. then when resolving
these symbols, fetching them from the table.

eg:
char *func_names[]={"malloc", "free", ..., NULL};
void FAR *func_ptrs[]={&malloc, &free, ..., NULL};


this is probably the simplest option.

 

[Bruce McFarling]

yes, you have the symbol table, for the LIB.
but, here is what you don't have:
the symbol table for the *EXE*.

Why is that a problem?

If, AFAIU, he has a .LIB file and wants to have interactive access to
the functions in the .LIB file via Forth, then if he wants to do it
via a symbol table, he compiles a symbol table. If he wants to do it
by defining index numbers for the library functions and calling a C
program with that index number to run the library function on his
behalf, he can do that.

 

[cr88192]

Why is that a problem?

consider, for example, the lib uses something like, say:
printf, malloc, fopen, ...

then, you have a problem.

why:
because these are part of the standard library, not part of the lib in question.

now, where is the standard library? it is linked into the EXE file.

so, absent having the EXE's symbol table, it is not possible to resolve the libraries' dependencies.


now, one can ask:
well, then, why can't you just link in a new copy of the standard library, and use that for the lib?...

well then, there is another problem:
the state is not shared between the main app and the library (for example, consider if they share memory or FILE's, or other parts of the standard library have state), well then, you have a problem...

so, what then if 2 versions of malloc go and, say, try to allocate the same region of memory, or free memory owned by the other malloc?...

or, any of the many other pieces of stdlib machinery?...


very likely, the thing will crash.

If, AFAIU, he has a .LIB file and wants to have interactive access to
the functions in the .LIB file via Forth, then if he wants to do it
via a symbol table, he compiles a symbol table. If he wants to do it
by defining index numbers for the library functions and calling a C
program with that index number to run the library function on his
behalf, he can do that.

wrong problem.

 

[Bruce McFarling]

now, where is the standard library? it is linked into the EXE file.

No, it isn't. Its in the standard library .LIB file that comes with
one of the DOS-era C-compilers that he says he has.

In particular, using the one approach that I suggested when he
explained what .LIB format he was talking about ... touching all of
the functions in the .LIB file that he wants to import by referring to
them by name in setting up the dispatch table, then having main() call
the Forth binary embedded into the program ... it does not seem that
the problem you suggest of not having a common state appears either.

This does underline a core obstacle one reading of the problem *as he
stated it*, which is to read it as the problem of using a library
designed to be statically compiled as a dynamic link library.

However on the other reading, that he wanted to *use* the functions in
the library dynamically, and wanted a way to do so, I think that the
technique already developed to use a binary Forth in the context of a
C program would make it reasonably straightforward to provide that.