Francois Gouget fgouget@free.fr writes:
I am not sure but I suspect the compiler generates indirect accesses for these. I'm not sure what gcc does for variables exported from another library. It seems like it has to be doing something similar. So if we could get access to that indirection we may be able to make things work.
Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO.
On December 2, 2002 02:03 pm, Alexandre Julliard wrote:
Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue.
Yes, having a PE-aware ld.so would allow us to bypass our import mechanism. But I guess the question was: given that we don't have such a ld.so, can we handle import of variables through our current import mechanism?
Since you mentioned portability, I would like to add that while worrying about compatibility makes sense, holding back features for long periods for the hope of finding the perfect portable solution probably hurts everyone.
Past experience has shown that having a working version for the dominant OS (Linux for us), is the way to go. The other systems will find a way of emulating the behavior faster (and better!) than we can figure out a good portable solution. We had the same debate about threading long ago, and at that time I was advocating using clone(2), but due to portability reasons threading support was delayed substantially. In the end, we ended up using clone, and it showed that (1) the hard part was to do the locking, and that was shared by all systems anyway, so progress on that front, even if only on Linux initially, helped _all_ systems, and (2) the *BSD folks come up with a solution in no time.
I know, it sounds selfish, but I think the best approach for everybody is to go ahead and implement it only on Linux if there isn't an obvious portable solution. The other systems will follow sooner rather than later. In the end, everybody wins.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Yes, having a PE-aware ld.so would allow us to bypass our import mechanism. But I guess the question was: given that we don't have such a ld.so, can we handle import of variables through our current import mechanism?
I don't see how. The compiler will generate references into the ELF GOT so you need to do the fixups there, which is basically what an ELF loader does. What we do for functions is to make the ELF loader link to our version of the function, and then jump to the real one; but of course this cannot work with variables.
-
Alexandre Julliard -
Dimitrie O. Paun