http://bugs.winehq.org/show_bug.cgi?id=10273
--- Comment #32 from Peter Beutner p.beutner@gmx.net 2007-11-17 11:29:02 --- (In reply to comment #28)
All functions that can be marked hidden already are, there's no possibility to do more in that area. We could probably fix a couple more functions by removing traces, but there isn't a lot of play here either. And considering that apparently many gcc versions work fine, I don't think it's worth a lot of effort to fix the few broken ones.
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)
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? When marking those functions hidden the number of functions that pass the safedisc test nearly doubles(from 143 to 242, if my testing app counts correctly, threshold is somewhere around 145). Imho that would be much safer than relying on the question if the gcc optimization of the day would still produce enough functions with a "safe" function entry sequence.
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.