This is the mail archive of the cygwin-apps 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: [Patch] Rebase: new switch --ephemeral


On Mon, Jun 18, 2012 at 3:58 AM, Corinna Vinschen  wrote:
> On Jun 13 21:19, ASSI wrote:
>> I've implemented a new option that allows to temporarily rebase some files
>> without messing up the rebase database. ?This is needed for instance when
>> one compiles Perl modules with DLL and wants to test them in the build
>> directory. ?I hope this can be implemented into the release version so that
>> this new feature can be used by cygport.
>>
>> A patch implementing the new feature is attached together with a Perl script
>> that can read out the information from the rebase database. ?There is no
>> immediate use for this script, but it might come in handy at times — my
>> first idea was to extract some information from the rebase database and use
>> this to do a manual rebase, but it turned out to be easier to implement
>> directly in rebase itself, so I went ahead and did that.

Great!
Did you see my perl-5.14 changes in EUMM for something like that?
http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/perl/pl-CYG07-cygwin_vendorarchautorebase-2.patch?spec=svn125&r=125

> The implementation of -E is a bit lacking, IMHO.
>
> The description implies that the ephemeral file list gets "also" rebased.
> So I take it that there are two lists of files, the ones which get
> rebased and are written back into the DB, and the ephemeral ones which
> get rebased but are not written back.
> However, if the -E option is used, your patch does not write back the DB
> at all. ?The result is that the DB will not reflect reality anymore for
> those DLLs which are supposed to be stored in the DB.
>
> Another problem is this. ?The idea of the DB stuff is to make sure that
> the DLLs on the system are rebased in a compact way. ?Since your
> ephemeral DLLs are handled exactly like the persistent DLLs in
> merge_image_info, the ephemeral and persistent DLLs memory addresses
> will be blended together. ?So you generate holes in the memory layout
> of the persistent DLLs, which is kind of contrary to the idea behind
> this.
>
> Therefore I'm wondering if it wouldn't be better to handle the ephemeral
> DLLs in a script, which rebases the DLLs below the lowest address in the
> DB. ?It should be pretty simple, kind of like this:
>
> ?low_addr=$(rebase -si | head -1 | awk '{ print $1 }')
> ?rebase -b $low_addr -d -T /path/to/ephemeral_dll_list

With 5.14 I check if the DLL already exists in the database and if the size
is not bigger I just use the old imagebase for the new and temp. DLL.
This will catch the previous errors in make test, with the dll in blib/arch
After installation the DLL will just reuse the old imagebase.

With changed size however I go the old perlrebase approach, which is
what Corinna did above.
I rebase it below, and not above. This is not good, but works around
most issues.

I'm not sure how to compact holes, other than rebaseall. baseing below
will conflict sooner or later
with the kernel and bigger apps, like MSIE, SQL Server, ... using more
and more space there.
It's getting worse, not better. Only 64bit will save us long-term.
-- 
Reini Urban
http://cpanel.net/ ? http://www.perl-compiler.org/


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