16 Dec
2007
16 Dec
'07
5:40 p.m.
Hi,
No, the problem is exactly choosing the address:
modules overlap with
each other, and manually calculating baseaddresses often doesn't
work.
OK, I see the problem.
There are not many dlls with baseaddress missing, and
if it's
missing, it should be added to those (in trunk).
You are correct, only a few have missing preferred load address; I created a
report http://www.codexchange.net/rosdoc/dllbaseaddresses.htm to help to
correct them.
The problem is to
distribute the dlls in the memory address space so that they don't
overlap.
As alex pointed there are two ways to accomplish it (I will add a third one)
A) create a new tool to investigate the build dll images , use it's file
size to distribute dlls in the memory space and generate baseaddress.xml .
run it from time to time.
PROS: Dll's will have always a predictable base address,
performance: optimal. Integrated with rbuild.
CONS: Dll's build with msvc will probably have different file size,
a valid calculated base address for a gcc build dll may become invalid when
build with msvc.
B) Make rbuild relocate base addresses on every build:
PROS: It will work with images generated no matter what compiler
because addresses are dynamically calculated.
CONS: Very inefficient, this process will be executed always. Even
when recompiling a single .c, Not integrated with rbuild.
C) Add a new report to rbuild (my approach): Inset of auto generating base
address and having the problems listed above we could add a new target "make
baseadressreport" which analyze the build dll images found on \obj-* (no
matter who compiled them) and use it's file size + module "baseaddress"
property to detect possible overlaps. By comparing reports with binaries
build by gcc and msvc we should be able to reconfigure base address to not
to conflict.
PROS: same advantages as case A. will work with images build by any
compiler but some fixes may be latter required based on report.easy to
implement.
CONS: baseaddress are still calculated by hand (but validated
automatically on request).
As for baseaddress in xml form - baseaddress is a
module's property,
it's not a standalone object which is part of the module. I don't see
why it should be given a standalone tag (maybe I'm missing something).
"property" IS actually an object, which is basically a generic key-value
container. The information it contains is *meaningless* to rbuild as it just
simply returns its value when someone reference it by his key. It can
contain anything from an empty string to Boolean or int ... .Rbuild don't
care about it as there is no way to validate the information they contain
because we don't know what to expect. "baseaddres" by contrast is a
specialized property (the C++ object is actually a property subclass so
technically still a property) which allows us to apply any particular logic
we desire to it , for example , generic property's value can be empty
baseaddres propery's value not. Generic property's value is not required to
be unique but baseaddres property must be. and so on...
Don't confuse rbuild xml syntax with objects as it's just a way to express
and persist the information. For example the "include" element <include
base="cacls"/>.</include> is also using an attribute to reference an
object
in this case a module, once it's resolved it only uses the module's path.
Same case as above.
Regards,
/Marc