[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 #33 from Alexandre Julliard <julliard at 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...


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