Re: ld --auto-imports

[Paul Sokolovsky <Paul dot Sokolovsky at technologist dot com>]

Hello Robert,

воскресенье, 10 июня 2001 г., you wrote to me:

RC> Hi Paul,
RC>     You may not recognise my name - I hack on the cygwin1.dll internals
RC> among other things. Ralf Habacker put me onto your auto-imports
RC> patch/hack for ld 2.11. I hope you don't mind me writing you direct, I
RC> wasn't sure hwat list was appropriate. Feel free to redirect me, or copy
RC> any reply to a list of your choice.

    I guess binutils list is a place to discuss this, and it fact I'd
appreciate such mails appearing there - likely, it won't be too easy
to get that patch included, so it would be nice if messages showing
that community reviews patch were sent there. I'm not subscribed to
it, however, so I'd appreciate cc: to me.

RC> Your ld patch looks very nice, and I have a modified libtool-HEAD here
RC> that using it rather than a 5 stage dllwrap process.

    You may want to know that I did it quite some time ago, along with
other useful changes. It is available at
http://sourceforge.net/projects/pw32/ . It worked OOB for me for stuff
I tried it on (glib/gtk+ libs, for example). Ralf Habacker reported it
worked ok for him with cygwin (even though package on the link above
built for my PW32).

RC> I've a small bit of feedback/a question, and a more serious question.

RC> Firstly the feedback. I'm using a pre-compiled version from Ralf
RC> habacker. That version (and AFAIK it's a stock build) creates the .dll
RC> base image at 0x610c0000 which collides with the cygwin1.dll. Now the
RC> cygwin1.dll is theoretically relocatable, but we've just found out that
RC> it doesn't like relocating :/. According to MSDN, the default image base
RC> for .dll's should be 0x10000000. Is there any reason your modified ld
RC> couldn't set that as the default base address for .dlls? That would
RC> remove the need to add --base-address=0x10000000 to the link line in
RC> libtool.

    Well:

1. As you understand, it is not connected with auto-import stuff in
any way. That's how Ralf Habacker built it.

2. Having specific base hardcoded is bad anyway - you'll get
collisions (automatically resolved, of course). Far better to
--enable-auto-image-base switch to ld and let it choose unique base
itself (based on hashing of dll name, etc.)

3. With my personal attitudes, ld on win32 should work as close to
normal unix version as possible. Mundane unix system doesn't have any
idiosynacrasies around "relocatability" - so, --enable-auto-image-base
should be the default as it offers most seamless solution to win32
strangeness. The same for --enable-auto-import . That's how I tried to
do while maintaining binutild fow Mingw32. Well, new maintainer
doesn't share these ideas, so having that all in libtool is not worst
solution ;-)

RC> Now for the more serious question. Does your patch in theory support
RC> dll's linking to other .dll's with auto-imports?

    Of course, why not? I wouldn't claim I tested that, however.

RC> I have a trivial hello
RC> world case here (built with my libtool, but I'm very sure the symptoms
RC> will be the same without libtool) that segfaults _every time_. That
RC> testcase has 3 source files, 2 libraries.
RC> hello.exe - depends on cyghello-0.dll
RC> cyghello-0.dll - depends on cyggreet-0.dll

RC> cyghello-0.dll reads a string from cyggreet-0.dll, and writes it + ,
RC> World! to stdout.

RC> Thanks for any suggestions you can offer. I'm happy to drop you the
RC> trivial testcase, and/or prepare a non-libtool testcase that shows the
RC> same symptoms - if that would help.

    Please provide one. I'd appeciate if it were not just mere gcc/ld
based, but also wouldn't depend on cygwin (i.e. were built with
-mno-cygwin or standalone mingw).

RC> Rob




--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135