Brian Dessent <[EMAIL PROTECTED]> writes:
> Ross Patterson wrote:
>
>> I'd still like to understand how one chooses base address and offset
>> values for rebase, seeing as I was just shooting in the dark until
>> something said "OWW!" :)
>
> Well normally you don't really choose anything. There
On Tue, Jan 16, 2007 at 10:13:17AM -0800, Brian Dessent wrote:
>Robin Walker wrote:
>>Thanks for the explanations. So, if I've understood things correctly,
>>the difficulty boils down to cloning a parent process's address space
>>layout within that of a child, which includes ensuring that DLLs app
Dave Korn wrote:
> We probably still would. First, the hash might collide and put two dlls in
> the same slot, and second, any dll greater than 1Mb overlaps into the next
> hash slot.
Well, if we found either of those things happening I think the logical
choice would be to robustify the hashin
On 16 January 2007 18:49, Brian Dessent wrote:
>
> static unsigned long
> compute_dll_image_base (const char *ofile)
> {
> unsigned long hash = strhash (ofile);
> return 0x6130 + ((hash << 16) & 0x0FFC);
> }
>
> ..which means it will end up somewhere between 0x6130 and
> 0x712C0
Robin Walker <[EMAIL PROTECTED]> writes:
> --On 16 January 2007 10:09 -0800 Ross Patterson wrote:
>
>> This has been an illuminating discussion and has given a lot more
>> detail to what I already understood about the rebase/fork issue.
>>
>> I'd still like to understand how one chooses base addre
Ross Patterson wrote:
> I'd still like to understand how one chooses base address and offset
> values for rebase, seeing as I was just shooting in the dark until
> something said "OWW!" :)
Well normally you don't really choose anything. There are two ways to
assign the base address. And again
--On 16 January 2007 10:09 -0800 Ross Patterson wrote:
This has been an illuminating discussion and has given a lot more
detail to what I already understood about the rebase/fork issue.
I'd still like to understand how one chooses base address and offset
values for rebase, seeing as I was just
Robin Walker wrote:
> Thanks for the explanations. So, if I've understood things correctly, the
> difficulty boils down to cloning a parent process's address space layout
> within that of a child, which includes ensuring that DLLs appear at the
> same base within both processes.
Note that the "c
Christopher Faylor <[EMAIL PROTECTED]> writes:
> On Tue, Jan 16, 2007 at 05:50:06PM +, Robin Walker wrote:
>>For this to be the problem it appears to be, I'm guessing that there must
>>be some shortcoming in the Windows APIs in this area when compared with
>>facilities available within other
On Tue, Jan 16, 2007 at 05:50:06PM +, Robin Walker wrote:
>For this to be the problem it appears to be, I'm guessing that there must
>be some shortcoming in the Windows APIs in this area when compared with
>facilities available within other Posix-compliant OSs.
It isn't a shortcoming at all.
--On 16 January 2007 04:58 -0800 Brian Dessent wrote:
Because in order to emulate fork(), Cygwin has to be able to re-execute
the binary and have it load with the same memory layout. If there are
DLLs that overlap and need remapping by the OS then the memory layout
becomes non-deterministic. I
Brian Dessent wrote:
> Because in order to emulate fork(), Cygwin has to be able to re-execute
> the binary and have it load with the same memory layout. If there are
> DLLs that overlap and need remapping by the OS then the memory layout
> becomes non-deterministic. If Cygwin cannot create a ch
On Tue, Jan 16, 2007 at 12:32:02PM +, Robin Walker wrote:
>--On 16 January 2007 07:12 -0500 Christopher Faylor wrote:
>>On Tue, Jan 16, 2007 at 11:37:46AM +, Robin Walker wrote:
>>>So, what is it about Cygwin DLLs that makes them apparently sensitive to
>>>base address in a way that normal
--On 16 January 2007 07:12 -0500 Christopher Faylor wrote:
On Tue, Jan 16, 2007 at 11:37:46AM +, Robin Walker wrote:
So, what is it about Cygwin DLLs that makes them apparently sensitive to
base address in a way that normal Windows DLLs are not?
"fork()"
Sorry, I don't understand this r
Robin Walker wrote:
> So, what is it about Cygwin DLLs that makes them apparently sensitive to
> base address in a way that normal Windows DLLs are not?
Because in order to emulate fork(), Cygwin has to be able to re-execute
the binary and have it load with the same memory layout. If there are
D
On Tue, Jan 16, 2007 at 11:37:46AM +, Robin Walker wrote:
>So, what is it about Cygwin DLLs that makes them apparently sensitive to
>base address in a way that normal Windows DLLs are not?
"fork()"
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
--On 15 January 2007 15:42 -0800 Ross Patterson wrote:
But I'm also curious about rebase and to understand more about how one
chooses what base address and offset to use.
My curiosity is deeper than that. I would welcome some instruction or
elucidation on this issue.
My understanding (plea
I recently was forced to build PIL under Cygwin Python 2.4.3 and ran
into the Cygwin fork/rebase issue with TCL/TK yet again.
Unfortunately, none of the rebase workarounds I found through my
copious STFWing worked this time.
Through trial and error I found that the following worked:
rebase -b 0x1
18 matches
Mail list logo
