This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rebase for setup.

----- Original Message -----
From: "Jason Tishler" <>

> Unfortunately, it does not actually handle pathological (or should I
> 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.


> 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
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]