Prev: If you don't immediately see your CLAX post...
Next: New to Assembly x86, DOS, Help needed.
From: Rod Pemberton on 18 Apr 2010 14:15
"peter" <cmk128(a)gmail.com> wrote in message
news:f5d9ee05-da8e-4695-8f3b-7e3289e5a03c(a)c42g2000yqn.googlegroups.com...
>
> Shared library with Position-
> indepedent-Code can be share in RAM.
> But non-PIC shared library
> cannot.
>

Really? Why not?

If the non-PIC code is reentrant...
http://en.wikipedia.org/wiki/Reentrant_(subroutine)


Rod Pemberton


From: BGB / cr88192 on 18 Apr 2010 14:18

"Robert Redelmeier" <redelm(a)ev1.net.invalid> wrote in message
news:hqfetv$d07$1(a)speranza.aioe.org...
> peter <cmk128(a)gmail.com> wrote in part:
>> Thanks Robert, completely understand now.
>> Just want to clarify one thing : Shared library with
>> Position- indepedent-Code can be share in RAM. But non-PIC
>> shared library cannot. The only one advantage of non-PIC
>> shared library is to save disk space. Right? thanks
>
>
> That may be too restrictive. While AFAIK libraries are
> normally written with PIC, they do not need to be: Each process
> has its own memory map set by the OS and invisible to the app.
> So long as the OS can load or remap the posn' dependant code
> at the required addr, everything is fine.
>

yeah.

by default Windows (the main user of non-PIC libraries) always tries to map
DLL's to a particular default address, and maps them between processes.
AFAIK, if it can't do this, it "rebases" the library (loads it at a new
address) and (maybe/dunno) tries to share this rebased version between
processes as well.

EXE's can typically only be loaded at a certain fixed address by default
(for whatever reason MS thought this was a good idea, but IIRC this can be
adjusted with commandline options when linking).

as noted, any data pages typically end up being duplicated when written, but
this is no big cost (and as well, the bulk of most DLL's tends to be code
and constant data, and so this cost is typically minor).


> What is more difficult is self-modifying code (SMC). This
> cannot be shared, but will trigger a CoW fault and a copy
> will be made. Fortunately, SMC is rarely justified.
>

as well, SMC is not generally used with statically compiled code.
IME, in cases where I have used it, it has almost always been in executable
allocated memory (and is typically not SMC in the traditional sense, but
more dynamically-generated code which may sometimes share pages with prior
dynamically-generated code, or reuse memory from prior code if it is GC'ed,
although much of my dynamically-generated code is not GC'ed for various
reasons...).

or such...


>
> -- Robert
>


From: BGB / cr88192 on 20 Apr 2010 00:17

<robertwessel2(a)yahoo.com> wrote in message
news:c2e66532-997e-4600-97f2-3d288ca9f7fd(a)y3g2000vbg.googlegroups.com...
On Apr 18, 1:18 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote:
> EXE's can typically only be loaded at a certain fixed address by default
> (for whatever reason MS thought this was a good idea, but IIRC this can be
> adjusted with commandline options when linking).

<--
Since only one (base) EXE can be loaded in an address space/process,
basing them all at the same place is easy, and doesn't result in any
collisions. Having an executable based to the correct location speeds
up load times, because the executable (DLL, EXE, or whatever) image
does not have to be relocated and patched as it's being loaded. Note
that some developers of some systems deliberately managed the default
bases for DLLs so that they load quickly too (by making sure all the
default bases resulting in no overlap). And since there can be only
one EXE in an address space, and thus it cannot collide at its default
base, omitting the relocation information makes the resulting EXE file
smaller.
-->

however, doing so does preclude doing an implementation (custom PE/COFF
loader/VM/OS) which supports using ASLR or similar on the main EXE. however,
ASLR on the DLL's may be good enough, since usually AFAIK it would be stuff
in the DLL's being the main target of any injected code anyways.

for example, my x86 interpreter does ASLR, although typically only on the
DLL's (granted, my interpreter doesn't currently support copy-on-write, but
little prevents doing "shared rebasing" + ASLR for any common DLL's).


assigned bases are not likely to work nearly as well if/when an app mixes
multiple DLL's from different developers, but a shared-rebase strategy could
work out better (since the OS could assign load-bases to every DLL
encountered and thus generally minimize clashes).


another possibility would be to assign semi-random numbers into the load
addresses, which would mix better with an OS like Windows, but if the space
is large enough, then this could risk overly fragmenting the address space
(likely to be especially a problem on 32-bit x86, since an app can easily
end up working with memory objects which are a non-trivial part of the total
address space...).

but, an example of this strategy could be like:
0x00000000..0x04000000 (size=64MB, app-local heap and DLL's)
0x04000000..0x10000000 (size=192MB, window for randomized DLL addr
assignment)
0x10000000..0x70000000 (size=1536MB, left for app-local heap)
0x70000000..0x80000000 (size=256MB, left for OS DLL's).
0x80000000..0xC0000000 (size=1024MB, available if app is "large address
aware")
0xC0000000..0xFFFFFFF (left for kernel or whatever)

this goes along with the usual defaults (if I remember correctly):
EXE default base 0x00400000;
DLL default base 0x01000000;
....


although I guess probably better is if apps don't assume the ability to just
malloc 256 or 512MB and assume that it will actually work (and my heaps
usually allocate memory in smaller chunks, typically 1MB for the
small-object heap, but maybe larger for the large-object heap).


but, OTOH, on x86-64 I use VirtualAlloc to grab a solid 2GB of address space
for something (mostly so that I can allocate it piecemeal and ensure a +-2GB
locality), so this sort of activity may be unavoidable.


<--
And yes, you can explicitly specify both the default base address and
whether or not relocation information is included in the executable
(again, DLL, EXE or whatever). The default bases for DLLs and EXEs
are different, and EXEs default to not including relocation
information.
-->

yep.

I was not certain, since I thought I remembered seeing a commandline option
for this, but wasn't sure.
I remember though the decided lack of a commandline option to leave in a
symbol table, which at the time was frustrating (since MinGW had tended to
do this, and I had tended to depend on it).

after the switch, I ended up DLL'ifying much of the project, and then
generally using exports rather than explicit symbol tables (and hackish code
to read-in the COFF symbol tables and try to match them against the loaded
modules...), ...

although, DLL's have their own annoyances as well, like them having to
reside on the path otherwise the loader will fail, ...

but, then again, one can debate whether it is better to have 15-20MB of
DLL's and a bunch of small EXE's, or a bunch of 15-20MB EXE's...


or such...


From: robertwessel2 on 19 Apr 2010 22:54
On Apr 18, 1:18 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote:
> EXE's can typically only be loaded at a certain fixed address by default
> (for whatever reason MS thought this was a good idea, but IIRC this can be
> adjusted with commandline options when linking).


Since only one (base) EXE can be loaded in an address space/process,
basing them all at the same place is easy, and doesn't result in any
collisions. Having an executable based to the correct location speeds
up load times, because the executable (DLL, EXE, or whatever) image
does not have to be relocated and patched as it's being loaded. Note
that some developers of some systems deliberately managed the default
bases for DLLs so that they load quickly too (by making sure all the
default bases resulting in no overlap). And since there can be only
one EXE in an address space, and thus it cannot collide at its default
base, omitting the relocation information makes the resulting EXE file
smaller.

And yes, you can explicitly specify both the default base address and
whether or not relocation information is included in the executable
(again, DLL, EXE or whatever). The default bases for DLLs and EXEs
are different, and EXEs default to not including relocation
information.
From: peter on 21 Apr 2010 21:48
thank you everybody
First  |  Prev  | 
Pages: 1 2 3
Prev: If you don't immediately see your CLAX post...
Next: New to Assembly x86, DOS, Help needed.