http://bugs.winehq.org/show_bug.cgi?id=10273
--- Comment #33 from Alexandre Julliard julliard@winehq.org 2007-11-18 07:21:43 --- (In reply to comment #32)
hmm, you can hardly call the compiler broken just because it loads the PIC register during the first eight instructions and not one or two instructions later. And relying that much on a specific function entry sequence seems rather fragile to me.(and the fact worries me that the working gcc versions are mostly older ones, while the most recent ones(4.2.2 and some 4.3 snapshot i tested) don't work)
I'm not saying the compiler is broken in general (though that may well be true of many 4.0 versions...)
Anyway, thinking about it I was wondering if we couldn't do more using the visibility attribute. Shouldn't it be possible to mark the exported API functions of a dll with visibility=hidden as well? Because (if I see this correctly) as far as the elf linker is concerned they don't need to be exported at all. When you link a dll/program against lets say user32, no user32 api reference actually is linked to the corresponding symbol in user32.dll.so. Instead they are linked to the PE import table that winebuild/winegcc creates and links into that dll/program. So as long as everybody uses winegcc/winebuild you can mark everything in the dll as hidden. Or am I missing something?
They need to be exported for the benefit of C++ winelib apps that need to import some dlls directly (like a gcc-compiled mfc), because the name mangling of gcc is not compatible with msvc.
Another option would be to mark these functions with visibility=protected, which means that every references to symbols defined in the same object are satisfied locally, i.e. calling functions in the same dll don't go through the plt. But the symbols are still exported and visible outside the library. That doesn't work for functions where at some point a reference to that function is used, but that are only a few cases(3 in user32). Though I vaguely remember having read somewhere that using "protected" isn't as optimal as it sounds.
The semantics of protected would be what we need, but yes, I don't think it works all that well in practice.
The only really foolproof way would be to hack gcc to not put a call in the first 8 instructions. But I think the chances of getting such a patch into upstream gcc is fairly small...