[Bug 10273] satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins (affects e.g. photoshop)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10273





--- Comment #32 from Peter Beutner <p.beutner at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.