Hi,
I am a novice developer with a question about the spec files.
Currently the .spec files contain stub lines for functions which have no implementation, and the compiler creates assembly thunks to __wine_spec_unimplemented_stub, which raises an exception when the function is called.
However, some entries in the spec files are actually not functions but data, and when applications attempt to read this data they instead read the instruction code of the thunks. I recently was debugging a 16-bit application [1] which was referring to a GUID that I could not find defined anywhere, and only after some time was able to figure out that the application was reading the thunk code for _IID_IClassFactory in this way.
The NE segment loading code in krnl386.dll16 will print a warning if an application attempts to request the location of a symbol not defined in the library. However, since the stubs are defined, no such message is printed, but the program will effectively be given a pointer to junk memory. As far as I can tell there is no way to add such a message either.
What would in fact work is not to implement stub code in the libraries at all. In 16-bit code this results in a warning when the value is accessed, followed by a crash if it is a function which the code attempts to call. In 32-bit code this seems to behave identically to a stub function. Thus the only difference is that in 16-bit code (and possibly 32-bit code, but I could not find any variable that I could test with) a warning is printed (and 0xdeadbeef is returned instead of junk memory), which I see as a definite improvement. By commenting out all of the stub lines in compobj.dll16.spec I was able to locate several more that the program requested, but I may still be missing some in other DLLs.
My question, then, is—is there any purpose of the stub lines besides to directly call __wine_spec_unimplemented_stub, or any other reason why this proposal would be detrimental?
Thanks, Zebediah Figura
Am 2017-02-01 um 20:37 schrieb Zebediah Figura:
My question, then, is—is there any purpose of the stub lines besides to directly call __wine_spec_unimplemented_stub, or any other reason why this proposal would be detrimental?
I am not an expert on .spec files and I am not sure if I understand your proposal correctly.
If you remove the stub lines GetProcAddress on the symbol will return NULL, and applications might take a different codepath based on that. Also the crash from calling a stub is fairly specific ("Unimplemented function XXX called") while the one from a nonexistent one that is resolved on library load is more generic (Access violation). You have the load-time warning, but you don't know if that warning has a relation to a crash much later on. Things are even trickier if the program has a signal handler for access violations.
Maybe we need a different kind of stub for data exports that point to a X byte large block filled with 0xdeadcode?
On 02/01/2017 03:08 PM, Stefan Dösinger wrote:
Am 2017-02-01 um 20:37 schrieb Zebediah Figura:
My question, then, is—is there any purpose of the stub lines besides to directly call __wine_spec_unimplemented_stub, or any other reason why this proposal would be detrimental?
I am not an expert on .spec files and I am not sure if I understand your proposal correctly.
If you remove the stub lines GetProcAddress on the symbol will return NULL, and applications might take a different codepath based on that.
Is there any way in which "applications might take a different codepath" would be worse than simply crashing?
Also the crash from calling a stub is fairly specific ("Unimplemented function XXX called") while the one from a nonexistent one that is resolved on library load is more generic (Access violation). You have the load-time warning, but you don't know if that warning has a relation to a crash much later on. Things are even trickier if the program has a signal handler for access violations.
For what it's worth, the error message I get for the (one) 32-bit function that I tested was identical. For 16 bit the stub gives me
wine: Call from 0x7b43c26c to unimplemented function compobj.dll16.COINITIALIZE, aborting wine: Unimplemented function compobj.dll16.COINITIALIZE called at address 0x7b43c26c (thread 0030), starting debugger...
while the nonexistent one gives me
err:fixup:apply_relocations No implementation for COMPOBJ.2, setting to 0xdeadbeef wine: Unhandled page fault on read access to 0x0000dea8 at address 0x101f:0x000017c3 (thread 0030), starting debugger...
The latter is a bit less obvious, but my reasoning is that a "no implementation" line should be enough of a red flag that the generic exception (or other misbehavior) could still be as easily fixed.
Maybe we need a different kind of stub for data exports that point to a X byte large block filled with 0xdeadcode?
This could work, but there is the problem that most of the stub constants that I found weren't outputted to the console. I only noticed the one because it showed up in a FIXME line for a function I was trying to implement.
Also, is there any way of actually telling whether a DLL export is a function or a constant?
Zebediah Figura z.figura12@gmail.com writes:
For what it's worth, the error message I get for the (one) 32-bit function that I tested was identical. For 16 bit the stub gives me
wine: Call from 0x7b43c26c to unimplemented function compobj.dll16.COINITIALIZE, aborting wine: Unimplemented function compobj.dll16.COINITIALIZE called at address 0x7b43c26c (thread 0030), starting debugger...
while the nonexistent one gives me
err:fixup:apply_relocations No implementation for COMPOBJ.2, setting to 0xdeadbeef wine: Unhandled page fault on read access to 0x0000dea8 at address 0x101f:0x000017c3 (thread 0030), starting debugger...
The latter is a bit less obvious, but my reasoning is that a "no implementation" line should be enough of a red flag that the generic exception (or other misbehavior) could still be as easily fixed.
For functions that are imported at link time, we can generate a stub or a dummy pointer, and print a warning. That's not the case for GetProcAddress, so the stub entries are still needed.
Maybe we need a different kind of stub for data exports that point to a X byte large block filled with 0xdeadcode?
This could work, but there is the problem that most of the stub constants that I found weren't outputted to the console. I only noticed the one because it showed up in a FIXME line for a function I was trying to implement.
Also, is there any way of actually telling whether a DLL export is a function or a constant?
Not in general, which is why they are all marked as stub since that's the case 99.9% of the time. Once we find out that one of them is supposed to be a data export, we can comment the stub out, or better simply implement it.
On 02/02/2017 02:46 AM, Alexandre Julliard wrote:
Zebediah Figura z.figura12@gmail.com writes:
For what it's worth, the error message I get for the (one) 32-bit function that I tested was identical. For 16 bit the stub gives me
wine: Call from 0x7b43c26c to unimplemented function compobj.dll16.COINITIALIZE, aborting wine: Unimplemented function compobj.dll16.COINITIALIZE called at address 0x7b43c26c (thread 0030), starting debugger...
while the nonexistent one gives me
err:fixup:apply_relocations No implementation for COMPOBJ.2, setting to 0xdeadbeef wine: Unhandled page fault on read access to 0x0000dea8 at address 0x101f:0x000017c3 (thread 0030), starting debugger...
The latter is a bit less obvious, but my reasoning is that a "no implementation" line should be enough of a red flag that the generic exception (or other misbehavior) could still be as easily fixed.
For functions that are imported at link time, we can generate a stub or a dummy pointer, and print a warning. That's not the case for GetProcAddress, so the stub entries are still needed.
Ah, I see; thank you for clearing that up.
-
Alexandre Julliard -
Stefan Dösinger -
Zebediah Figura