Mail Archives: cygwin-apps/2002/01/03/08:21:10
----- Original Message -----
From: "Jason Tishler" <jason AT tishler DOT net>
> Unfortunately, it does not actually handle pathological (or should I
say
> incestuous) programs such as Python that use freshly built components
> (i.e., DLLs) during the build process itself.
>
> Does it make any sense to change Cygwin's ld to rebase on the fly
> instead?
Ah, well that's easy. Shoot python :]. This is why I suggested a bfd
based rebase, rather than the MS function orginally - so that binutils
can do this natively, and yes I think that this would be good - but the
system database then gets tightly linked to bfd - urgh. The layering
needs more thought I think.
> > Mine is "rebase everything that appears linked" "x bytes apart". The
> > goal being to avoid rebasing 1000 .dll and .exe's when you run setup
> > and
> > install fortune.exe :}.
>
> Do we really need to rebase the .exe's? If not, then the I only count
> 113 Cygwin DLLs in my system. Besides rebasing seems to be quick.
.exes can be loaded via dlopen. (didn't know that huh? :]).
> > That requires persistent storage of the used
> > address range, thus storing the info in /etc/setup.
>
> I understood this part, given that your rebase algorithm is used --
> I just wasn't sure why the simple one wouldn't work.
We've only got 2Gb to play with. Programs with large datasets -
postgresql for instance - may need as much of that as possible. As the
number of .dll's and .exes grow this will become a bigger issue. A
debian box I upgraded today has 48000 files installed, with probably 5%
library or .exe's. So that's starting to eat into that 2Gb quite fast.
> > loadable modules probably need some thought in this context though.
>
> By "loadable," do you mean dlopen-ed DLLs? If so, then definitely --
> Python has a bunch of them.
Yes.
> A couple of more issues to deal with:
>
> 1. Determine why cygcurl-2.dll and possibly other DLLs do not tolerate
> rebasing.
Hmm. Yes. Did you rebase .dll's after stripping them? And what strip
options where used?
> 2. Make sure whatever algorithm that we use can handle non-relocatable
> DLLs without getting confused or wasting address space. (The current
> version of rebase would waste the offset value (e.g., 0x10000) of
address
> space on cygtclpip80.dll).
The algorithm I proposed does ('find available space'). That could be
tuned a bit, we still need to isolate how much offset is needed, and
where it really needs to be.
Rob
- Raw text -