verma wrote:
> Dear ALL,
>
> I am trying to reduce startup time of my application using CRLE.
> I have created Alternative objects using crle for my executale.
> I have found one docs related to this and then I did the following to create
> altrenative objects
>
> crle -c \
> ./CRLE/config \
> -f RTLD_REL_ALL \
> -G /work/CP0003/test
>
> but when I run my application "test" this gives me segmentation fault
> in case if I changed flag "-f RTLD_REL_ALL" to "-f RTLD_REL_EXEC" then my
> executable run well.
> could you please help me to sort out this why this is happening?
I can only guess, because you haven't given any information as to what
segmentation fault you have.
There is a conspiracy of many things when you use crle(1) to create alternative
objects. This is a power tool.
Your use of -G results in the application and all of its dependencies
being dldump(3c)'ed into the CRLE directory.
The use of "-f RTLD_REL_ALL" binds all the relocations between all of the
dumped objects. This means that the objects must be reused as a family.
You can't mix these objects with their other system counterparts.
To ensure this family is used together, and the appropriate memory reservations
are made to allow this family to be mapped, a configuration file is used that
provides the necessary information to ld.so.1(1).
The trick is to make sure that the execution of the dumped executable uses
the configuration file.
When ld.so.1 detects a "dumped" application, it fabricates a configuration file
name to search for. If you wish to override this, then use LD_CONFIG.
So, stepping through something that might mimic your example:
oxpoly 540. cat test.c
#include <stdio.h>
void main()
{
(void) printf("hello world\n");
}
oxpoly 541. cc -o test test.c
oxpoly 542. ldd test
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
oxpoly 543. ./test
hello world
Now let's create some alternatives:
oxpoly 544. mkdir CRLE
oxpoly 545. crle -c CRLE/config -f RTLD_REL_ALL -G test
oxpoly 546. crle -c CRLE/config
Configuration file [version 4]: CRLE/config [ RTLD_REL_ALL ]
.....
We have a config file, but by default it won't be used:
oxpoly 547. LD_DEBUG=basic CRLE/test
08669:
08669: configuration file=/home/rie/verma/CRLE/ld.config.test: unable to
process
file
(the default naming convention is defined in the crle(1) man page).
The problem is more obvious when you look at what gets loaded:
oxpoly 548. ldd CRLE/test
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
You need to use the configuration file:
oxpoly 549. ldd -e LD_CONFIG=CRLE/config CRLE/test
libc.so.1 => /home/rie/verma/CRLE/libc.so.1 (alternate)
libm.so.2 => /home/rie/verma/CRLE/libm.so.2 (alternate)
/home/rie/verma/CRLE/libc_psr.so.1 (alternate)
or perhaps rename the original:
oxpoly 553. mv CRLE/config CRLE/ld.config.test
oxpoly 554. LD_DEBUG=basic CRLE/test
08680:
08680: configuration file=/home/rie/verma/CRLE/ld.config.test: [
DIRECTORY-CONFIG OBJECT-ALTERNATIVES MEMORY-RESERVATION FILTER-ASSOCIATIONS ]
Now things start to work:
oxpoly 556. ldd CRLE/test
libc.so.1 => /home/rie/verma/CRLE/libc.so.1 (alternate)
libm.so.2 => /home/rie/verma/CRLE/libm.so.2 (alternate)
/home/rie/verma/CRLE/libc_psr.so.1 (alternate)
oxpoly 557. CRLE/test
hello world
oxpoly 558.
> Another doubt:
> When I have measure time using "time" commands in both cases(without
> alternative object and with alternative object),same times comes and some
> times more time comes in alternative object case
> Why this happening since I have created alternative objects(pre-relocated
> object)
> so ld.so.1 should take less time to run my application using these
> alternative objects.
>
> is there any thing wrong with my testing procedure ?
We've experimented with crle(1) in this regard, and found that unless you have
a lot of dependencies with a lot of relocations, the reduction in work that
ld.so.1 has to do is hard to feel. Other aspects of processes, such as paging
activity because of no-locality of references, excessive .init code, etc. have
a much greater effect on overall performance.
As we never found any marked improvement in using crle(1) for the OS libraries,
we haven't used it in this mode, and it is left for more "specialized" purposes.
Note, there is no infrastructure for maintaining you cache of objects with
updates/patches etc. It's really all left to you.
--
Rod.
