[hatari-devel] Debugger crash changes / zeroing global variables
npomarede at corp.free.fr
Sat Jan 14 21:38:36 CET 2012
On 14/01/2012 16:53, Eero Tamminen wrote:
> Nicolas, what are these changes:
> Uninitialized global variables are already zero. Or your compiler
> is buggy, as C specification states that:
> If an object that has static storage duration is not initialized explicitly,
> if it has pointer type, it is initialized to a null pointer;
> if it has arithmetic type, it is initialized to (positive or unsigned) zero;
> if it is an aggregate, every member is initialized (recursively) according
> to these rules;
> if it is a union, the first named member is initialized (recursively)
> according to these rules.
> Explicitly setting global variables to NULL/zero/false, may move the
> variables from (initially zeroed) BSS to DATA section and increase
> the binary size minimally, it doesn't change the values of those
> variables as they already were zero. See also:
I.e. I think there's some other problem that you just hid.
yes, I know this is weird, but these 2 variables in debugui.c were
having strange values (debugOutput was always 0x060000 in my case, which
is not a valid file pointer).
I know global variables are supposed to be null, but in my case gdb
shown non-null values for both variables. I'm using gcc 4.6.2 (recent
snapshot), maybe it's a bug in it.
Explicitly setting them might move them from BSS to DATA, but on the
other hand, I think there should be a place where the default value is
explictly set, it's more readable when trying to understand what the
default values are in the source.
I just made the test again, I removed the explicit values in debugui.c :
make clean ; configure ; make
Then when I run hatari with transbeauce demo 2 disk 1, I'm sent to the
debugger. If I press 'c', I get 'return to emulation' and a crash :(
So, maybe there's another bug hiding somewhere (in debugui or gcc), but
I don't know where .
More information about the hatari-devel