bds2006 link/.exe related questions - problem search
dhoke
(If this is wrong newsgroup please advise - other linker issues seem to have
been addressed in this group.)
(Also sorry for post length, but I think this is minimum necessary to
adequately describe context for the curious, and present questions to those
who might be able to help.)
[background summary]
I am trying to figure out whether an application under development, or its
supporting libraries, may contain a problem (I do not have access to source
for all code involved), or whether I am tripping a linker bug that is
causing it to produce a bad executable. More background below if
interested.
[questions]
What determines the address ordering assignment of modules linked by bds2006
linker (sp2, hotfixrollup2)?
Is it predictable whether two entirely separate build treess, built with
precisely the same steps, will produce precisely the same executable, except
for any path-related and time-stamp related information in the resulting
executable that might have been influenced by the leading build path(s) and
time of build?
Would the length of the directory paths leading to two completely identical
build trees built with precisely the same steps (directory paths involved
excluded from "same") be expected to influence (change) the ordering of
addresses assigned to linked modules, in the two different build trees? If
so, is the influence predictable? If predictable, what influence occurs?
Is a 9MB (9,376,256 bytes - currently no code optimization in code I
compile) .exe a large application to be building with B/CG tools?
What easy way is there to explore what functional differences may exist in
two executables that should be entirely functionally equivalent (assumed
exact same code, albeit in possibly different sequences)?
Thanks.
[slightly more Background to above questions]
The same source control revision, cleanly fetched to two identical
previoiusly non-existent working directories, accessed via leading paths of
different length, built with exactly the same steps, produce executables,
that according to the .map files have different address orderings assigned
for various modules linked in.
One of the executables crashes predictably when built without codeguard, but
does not crash when built with codeguard (and codeguard build/run does not
report any errors that appear to be plausible causes of this - just leaks of
some items beyond my control on program shutdown.)
One executable does not crash (when built without codeguard - have not tried
it with codeguard.)
The crash in question occurs in a memcpy() with default memory manager, and
crashes in FastMM itself when that is used to replace the default memory
manager. (The replacement FastMM used is the one prebuilt for use with the
BDS IDE.)
The set of steps used to operate is equivalent in both crashing and
non-crashing runs, the one actual difference is in textual content entered
into two edit fields. That information is the same in form in both cases,
but contains incrementing sequence #'s, and buildtree path context
information (to identify attempted runs.)
The renaming of the directory paths leading to a given build tree, to one or
the other lengths, seems to be the controlling factor in the linkage order
of modules in the resulting executable.
But, is the module linkage order the trigger of the problem (that may really
exist in the code), or is one of the executables just plain bad, because of
the linker?
I acknowledge that such a manifestation could be due to at least
1)uninitialized memory, or 2)something related to global storage/variables,
that might be affected by the re-ordering of modules.
Disassembling two 9MB executable files and attempting to textually compare
the two to search for possible functional differences, seems a very daunting
task since the linked code is apparently in different sequences in the two
.exes, despite all steps to production being equivalent.
dhoke
reported for the resulting segments are different between the two
executables, with the lengths for _TEXT/_DATA both being shorter in the
non-crashing executable. I realize this could be due merely to different
alignment/roundoff issues, due to the differing link order.
However, the length of at least two of the linked objs (from map file) are
reported as different
0xb19 vs 0x961 ( 2841 vs 2401 )
0x3a2 vs 0x55d ( 930 vs 1373 )
I hadn't checked this until after first post.
"dhoke" <dhoke....@east-shore.com> wrote in message
news:4632132e$1...@newsgroups.borland.com...
dhoke
from code I compile (have source to). One of them is from a library, the
other is part of the application project being run.
For the module from the library, in the rename directory scenario to
produce/avoid crash, the rebuild would not rebuild that library (its a
separate project), and so the input library/object should be exactly the
same to the linker for both the crashing and non-crashing .exe.
But, the .map file reports the library module as being a different length
when linked in.
Why is the same input object module reported as differing in length by 443
bytes, between the two executables?
Also, the detailed map of segments appears to list <addr>, <length>,
<C=item>, <S=item>, <G=item>, <M=path> etc.
I would have expected the addr-length items, being sorted by address, to
proceed from one item to the next, with the next possibly being greater,
than the value obtained by adding prev-addr plus prev-length. They are not,
in either of the map files. In various cases, the item-addr plus
item-length is beyond the following item-addr. What exactly are those
values representing?
Concrete example extracted from crashing map file
0001:0005FCA0 00010A21 C=CODE S=_TEXT G=(none) M=TPMAINFORM.OBJ
ACBP=A9
0001:000706C1 00000CF0 C=CODE S=_TEXT G=(none) M=TPSTATUS.OBJ
ACBP=A9
0001:000713A4 0000093D C=CODE S=_TEXT G=(none) M=DBACCESSTHR.OBJ
ACBP=A9
0x706c1 + 0xcf0 (tpstatus.obj) = 0x713b1, which falls beyond 0x713a4, the
start addr. of DBACCESSTHR.obj.
concrete example from non-crashing map file
0001:000706C1 0000055D C=CODE S=_TEXT G=(none) M=CardScanBase
ACBP=A9
0001:00070BF6 000007CE C=CODE S=_TEXT G=(none) M=cFormat2 ACBP=A9
0x706c1 + 0x55d (cardscanbase) = 0x70c1e, which falls beyond 0x70bf6, the
start addr. of cFormat2.
HELP!
"dhoke" <dhoke....@east-shore.com> wrote in message
news:46321966$1...@newsgroups.borland.com...
vavan
<dhoke....@east-shore.com> wrote:
did you try to use ulink to see if it produces different results?
--
Vladimir Ulchenko aka vavan
dhoke
linkers.
[trying to be humorous]
I can already get differing results out of the linker I have - why would I
want another one?
"vavan" <Vavan...@ThisSantel.ru> wrote in message
news:1fm533pnqp34ge6gj...@4ax.com...