This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: when to rebase?
On Tue, 24 Feb 2004, Jason Tishler wrote:
> Peter,
>
> On Fri, Feb 20, 2004 at 10:19:09PM -0800, Peter A. Castro wrote:
> > On Fri, 20 Feb 2004, Jason Tishler wrote:
> > > FWIW, I just tried the above with Microsoft's rebase and observed
> > > the same behavior. Note this is not a "ruling" just another data
> > > point.
> >
> > Well, considering what the root problem is, I wouldn't expect MS's
> > rebase to work any better than the cygwin version.
>
> Understood. However, one of my design goals for rebase was to behave as
> similar to Microsoft's as possible. This became especially true when I
> replaced Microsoft's ReBaseImage() with the one from Ralf Habacker's
> libimagehelper.
A worthy goal.
> > However, I would like to see some cooperation on how to resolve it.
>
> See below for one possible solution...
>
> > This problem is not specific to zsh.
>
> Understood.
>
> > It has more to do with how exported symbols are treated/managed.
>
> Or built...
Yes, yes...
> > I'd almost propose that rebase change such symbols' value, being
> > rebase is the one changing the image base of the dll in the first
> > place.
>
> Do others agree? If so, does anyone know how hard it would be to enhance
> libimagehelper to handle this case?
>
> > However, I would really like to understand why this symbol exists and
> > if there is some way to eliminate it and use the dll's real image base
> > instead.
>
> It appears that dllwrap *may* be the culprit. If I replace dllwrap with
> gcc -shared in your testscript, then the problem is avoided. See
> attached patch for the details.
I was a bit curious about this. dllwrap is just a convenient wrapper
around dlltool, which is supposed to be the tool of choice for creating
dlls, yes? Or has 'gcc -shared' supplanted dlltool? And, ultimately,
dlltool simply calls gcc with some different options. You can see this
yourself by adding a '-v' option to the dllwrap command in testscript.sh.
Here's a sample gcc line output by dllwrap/dlltool to create the dll:
-------------------------------------------------------------------------
gcc testdll.exp -Wl,--dll -nostartfiles -o testdll.dll
-Wl,-e,__cygwin_dll_entry@12 -Wl,--image-base,0x63780000 -v -g testdll.o -lc
-------------------------------------------------------------------------
And what gcc does (because of the -v):
-------------------------------------------------------------------------
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
Configured with: /netrel/src/gcc-3.3.1-2/configure
--enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix
--with-system-zlib --enable-nls --without-included-gettext
--enable-interpreter --enable-sjlj-exceptions
--disable-version-specific-runtime-libs --enable-shared
--build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin
--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--includedir=/nonexistent/include --libexecdir=/usr/sbin
Thread model: posix
gcc version 3.3.1 (cygming special)
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/collect2.exe -Bdynamic
--dll-search-prefix=cyg -o testdll.dll
-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1
-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../.. testdll.exp
--dll -e __cygwin_dll_entry@12 --image-base 0x63780000 testdll.o -lc -lgcc
-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
-------------------------------------------------------------------------
So, what's the difference? Apparently, only the options supplied to the
linker. I don't really understand, completely, the differences between
'-shared' and '-Wl,--dll', but I suspect it has more to do with Windows
compatability than anything else. '-shared' creates shared objects,
while '--dll' creates dlls (like shared objects) which supposedly can
interoperate with other compiler generated dlls (Visual C++, perhaps?).
I'm not sure that this is an advantage, give that within the cygwin
environment you can't really interoperate with Visual C++ generated dlls
anyways, so perhaps it's better to simple create cygwin only compatable
dlls instead.
> Can you use gcc -shared instead of dllwrap when you build zsh?
After a bit of experimenting and a few rebuilds using different options,
I've determined that using:
gcc -shared -Wl,--export-all-symbols
works best. There's apparently a subtle difference between this and
using '-Wl,-dll', which causes a conflict with rebasing.
Zsh uses global variables as well as exported functions, so using just
'gcc -shared' alone was insufficient (because the global vars weren't
being exported). While the build process for zsh takes care to extract
out exported functions and variables, there doesn't seem to be a
convenient way to actually use that info in building the shared libraries
themselves. One option is to explicitly mark for dllexport those globals
which are needed by other parts of zsh, but that's tedious. I also toyed
with hacking the makefiles to use the export list in the shared lib gen,
but I didn't really want to customize the makefiles that much (it
would've been invasive surgery to some extent), so I opted to make shared
library creation simply export everything, hence the
'-Wl,--export-all-symbols' option.
I've got some cleanup to do, then I'll post a new release of zsh which can
be safely rebased. :)
As a side note, this change appears to have fixed some other hidden
problem which was causing some of the Test cases for zsh to fail or hang
randomly. Perhaps this is an indication of just how unstable the --dll
linker option is, but that's just an observation (and probably wrong at
that :).
In anycase, zsh, for the moment, has side-stepped the issue. That's not
to say someone else won't hit this, but at least we have a known work
around. :)
> Thanks,
> Jason
--
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
"Cats are just autistic Dogs" -- Dr. Tony Attwood
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/