Re: Strange structure initialization problem.
On 10.02.15 06.56, DSF wrote:
[init local copy]
I believe this is what my compiler is automatically doing with any
structure or array initialization. It stores the literal numeric
values in a static area and then copies them into the structure.
Exactly.
> If I change the original to:
IOERRORS ret;
ret.ioerror = 0;
ret.syserror = 0;
It becomes:
; IOERRORS ret; // = {0, 0};
; ret.ioerror = 0;
@6:
xor eax,eax
mov dword ptr [ebp-8],eax
;
; ret.syserror = 0;
xor edx,edx
mov dword ptr [ebp-4],edx
Still stupid code.
Turn global register optimizations on (or however this was called at
Borland) and it will likely look more pretty. But your debugger will
dislike the result.
And it still creates/uses a local ret and copies
it to the LHS pointer on the stack at the end, even though there is
only one exit point.
The code in between usually need the registers for something else or
calls functions that do not guarantee to preserver their values.
Furthermore the debugger cannot access variable values that have no
memory representation. So using a register is not an option as long as
you have debugging enabled.
But at least I understand now; it's a
boilerplate for initialization.
2. The memory locations are referenced in entirely different ways.
That, as has been mentioned, is in linker territory.
It is up to the implementation to use one or another method.
Independently of your code.
However, there should also be an option to place compile time constants
in the code segment. This is not that natural.
Firstly because on some platforms read and execute access requires
different permissions. Think of the NX feature, although x86 learned
this quite lately.
Secondly in old C character constants like your "This is foo!" are of
type char* rather than const char*. This has the effect that when is is
passed to a function as char* argument the function is allowed to change
the value of this constant. That is the reason why they are normally
placed in the DATA segment rather than TEXT. This behavior is no longer
valid, but your compiler might still be compatible to that.
It turns out that FBaseString<wchar_t>::blank + 0x30 resolves to...
...wait for it...
Address 0x42a694! Which explains:
4. I have no idea what/where [0x42a698] refers to.
It's the address following FBaseString<wchar_t>::blank + 0x30!
So there we have our static storage of two unsigned integer zeros.
Probably. The compiler simply did not create a debugger symbol for its
internal constant. And the debugger uses the next best symbol with an
offset. This is nothing where the linker is involved. It is simple the
first symbol in the data segment of your compilation unit (.obj) and the
debugger uses the last symbol from the previous compilation unit,
unaware of compilation units.
Activate the assembler output of the compiler and you will see a
reasonable reference.
As to whether it's a compiler bug or an error of mine is yet to be
determined. But address 0x42a694 lies right in the middle of a buffer
of FBaseString and is overwritten near the end of the program loop
that this code is within.
Maybe you called free on memory not allocated before and the compiler
reused your memory.
Normally I would recommend to run your program with a memory analyzer
like valgrind. But with that old platform you may not have any option
like this.
I've also learned (at least while I'm using this compiler) to avoid
multiple exit points if I'm returning a structure. As a test I added
three return ret; statements to GetVolumeInfo. Each one produced:
mov eax,dword ptr [ebp+8]
mov edx,dword ptr [ebp-8]
mov dword ptr [eax],edx
mov edx,dword ptr [ebp-4]
mov dword ptr [eax+4],edx
mov eax,dword ptr [ebp+8]
jmp @12
Copying the *same* local variable to the stack for return. They may
use different registers to do it, but it's an exit point, negating any
later requirements on the register values.
- Turn on optimizations. For debugging purposes the compiler can neither
share nor interleave code between different source lines.
- Use a recent compiler. Many things happened in between.
The last one even has a convenient label. So instead of repeating
the 17-byte sequence each time, they should have dumped every mov
above and changed the last to jmp @8!
This is the common sub expression optimization. It has to be turned on
and the code has to fit into the analysis window.
Enough of this off topic typing. At least I think I know why some
of the strange code is implemented the way it is. And I know where
the error is. FBaseString<wchar_t>::blank is a const static value, so
it's reasonable that 0x30 farther on (0x42a694) is still in the static
area. The memory allocated for the string starts at 0x42a664. I
don't have an idea off the top of my head how to determine if it's a
bug or corrupt memory data.
I would guess some of your code has undefined behavior and the string
buffer never should point to that area. I have no idea what FBaseString
is and whether it allows to assign a buffer from outside. This might
explain everything.
Maybe you set some string class instance to blank, retrieved its address
as C compatible char* and then used this as strcpy target. Bad idea!
I'm just guessing, of course.
Again, turn on the option to place constants in the TEXT segment and you
will get a CPU exception when an instruction wants to write to the
constant. This won't prevent you from from doing other wired things with
pointers, but it will catch at least a few cases.
As rule of thumb: do not use the type char* anywhere in your C++ code.
Use your string class or const char* only. This will prevent you from
many problems.
I did not take care of wchar_t in my post. Everything which applies to
char applies to wchar_t as well.
Marcel