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