Eric Pouech wrote:
> thanks for taking a look at it. unfortunately, I couldn't really test
> your patches. when run, roughly 4/5 of the .so files did would generate
> this type of error
> ../../tools/strip_imports libwinspool.drv.so
> objcopy: styEor1D: File truncated
Strange. Could you try using 'strip' instead of 'objcopy' in
strip_imports? (Only there, in localize_imports it must be objcopy.)
> I couldn't get a more precise error message (binutils 2.9.1), nor an
> explanation (looks like an internal error but badly reported, it's not
> a disk full error). Any idea ? The core results was no action was taken
> on the file, so no lots of testing possible :-(
Even if strip_imports fails, this is not critical. The result is
just not as pretty, as the import stubs remain as (local-only)
symbols.
> From a pure conceptual point of view, the build process definitively
> grows more and more complex (I'm not sure Alexandre would accept another
> tool or an extension to winebuild for it). However, if I got what you intend
> correctly, it means that an import symbol would be defined as:
> - no trace in stabs
> - listed in .dynamic section, as a local symbol.
No, I mean no trace in stabs *and* no dynamic symbol either.
> I'm not sure this is sufficient to distinguish from other symbols (like, for
> example in the case of a Winelib program, for a local symbol in an
> assembly file). But, again, I may have gotten you wrong.
Maybe it's clearer with an example: comctl32 import CreateWindowExA from user32.
So, the comctl32 object files contain references to an undefined global symbol
'CreateWindowExA'. (At this point, dynamic symbols don't even exist yet.)
The winebuild tool generates an import stub, and defines the symbol
CreateWindowExA pointing to it. With my patch, it will *in addition*
create also a symbol __wine_dllimport_comctl32_CreateWindowExA pointing
to the same address.
Now, the spec.c file is compiled and linked together with the other
comctl32 objects into a single temporary object. This now contains
both a definition of CreateWindowExA and many references to it.
Now, if we would just create a shared object, the symbol would just
get converted to a dynamic symbol and the references would get
converted to dynamic references; nothing would get resolved. Dynamic
symbol resolution only takes place at runtime, taking into consideration
e.g. libraries preloaded with LD_PRELOAD which might force the reference
to get resolved to that outside library.
What Alexandre did was to link the shared object with -Bsymbolic.
This causes all references to CreateWindowExA be resolved directly to
the definition (the import stub); no dynamic references are created.
However, there is still a dynamic *symbol* CreateWindowExA created;
this is what can cause problems because now other shared objects
could dynamically resolve against that symbol.
What I am doing is this: first, the CreateWindowExA symbol is
*localized*, this means it will be treated from now on as if it
were defined as 'static'. (Note that since we linked everything
into one object file first, this has the same effect as if all
source files had been concatenated into a single source file,
and the import stub symbols defined static there.)
When this object is then linked into a shared object, all references
to CreateWindowExA are immediately resolved (no matter whether
-Bsymbolic is given or no), because this is always done for static
function definitions. Furthermore, there is no *dynamic* symbol
created either, because static functions aren't dynamically resolvable.
So, at this point, there is *no* dynamic symbol CreateWindowExA,
but there is still the local, non-dynamic symbol CreateWindowExA.
This is finally eliminated by the strip_imports command. After
that, there is neither a dynamic nor a standard CreateWindowExA
symbol.
However, there still *is* the new __wine_dllimports_comctl32_CreateWindowExA
symbol pointing to the location of the import stub. If you disassemble
the comctl32.so file, calls to CreateWindowExA will therefore be shown
as 'call __wine_dllimports_comctl32_CreateWindowExA'.
Now, you have every option in the debugger: the symbol CreateWindowExA
exists only once, at the actual definition, so you can easily set a
breakpoint there. On the other hand, if you for some reason need to,
you can also set a breakpoint on __wine_dllimports_comctl32_CreateWindowExA
and hit exactly *this* import stub, as opposed to the other import stubs
for CreateWindowExA that might exist.
You can trace through the import stub without getting confused;
or you could set up the debugger so that it knows that functions
with the name __wine_dllimports_* are always to be treated
transparently as trampolines ...
B.t.w. you could now leave off the -Bsymbolic option; this has
the advantage that the linking of ELF symbols behaves according
to the usual ELF rules, e.g. LD_PRELOAD will work again. (Think
e.g. preloading a SOCKS library in
