David Bacon wrote:
Your clock seems to be running very slow, or else I’ve forgotten
what time zone I’m in. >
Hmmm, my post shows here as being at 14:37 PST (which is when it was).
Anyway, I take it from the assembly code that event_msg.class_num is
an unsigned short, and that the elements of Low_level_class_ptr are
32 bytes wide (“sall” is clearly a “shift left” instruction).
Excuse my ignorance, I have almost 0 gnu assembler time…
Not too much optimization there, judging from the first two “movl”
instructions, so> optimization isn’t the issue.
That’s the conclusion I came to (particularly when -O0 produced the same
The low_level_sub_class_ptr would be the last field in the struct or
class describing those array elements, and the long and the short
of it is that there appears to be nothing whatsoever wrong with the
generated code if the foregoing inferences are all correct. (I agree
with your “Looks like…” statement, of course.) You presumably
have your own reasons for indexing the array with
event_msg.class_num rather than with i;
Not my reasons; this is code I have inherited - could just as easily be
indexed with i (event_msg.class_num needs to be initialized by the same
loop). The program this comes from is about 180,000 lines of code, and
this is the only place where there appears to be an issue, and it is
100% repeatable (even the garbage value that is stored in LLSCptr is
always the same).
it might be interesting to see what the debugger has to say about the
value of Low_level_class_ptr> .low_level_sub_class_ptr.
_The debugger prints the same (correct) value for this array indexed
with either i or event_msg.class_num or the immediate value 0 (which is
what both i and event_msg.class_num are when the problem occurs). The
problem is that the code that assigns the value to the stack location
-44 doesn’t work (why it doesn’t work is a mystery to me at this point).
Here is screenshot from an actual debug session (the code is inside a
function called SendAllDevicesOnline.
Breakpoint 4, SendAllDevicesOnline () at Online.cpp:201
201 for (i = 0; i < HIGH_LEVEL_DEVICE_CLASS; i++)
203 event_msg.class_num = i;
(gdb) p event_msg.class_num
$1 = 20
204 LLSCptr = Low_level_class_ptr[ event_msg.class_num].low_level_sub_class_ptr;
(gdb) p event_msg.class_num
$2 = 0
(gdb) p Low_level_class_ptr[event_msg.class_num].low_level_sub_class_ptr
$3 = (struct low_level_sub_class_struct *) 0x80acac8
205 if ( LLSCptr != NULL)
(gdb) p LLSCptr
$4 = (struct low_level_sub_class_struct *) 0x1080a
The bogus value for LLSCptr is always 0x1080a. 0x80acac8 is correct (at
least I can safely de-reference it)._
Could you possibly post a self-contained program which demonstrates
the problem. A code generation or debugger bug provoked by such
innocent code would be of great interest to many! Thanks
I could provide you the whole program, but I doubt that I could snip
this code out of the environment and have it behave this way, since (as
you imply) this would have been caught long ago.
With the whole program, you could re-produce the above debug session in
less than 5 minutes. The question is: how can line 204 can be executed,
with the result “LLSCptr != Low_level_class_ptr.low_level_sub_class_ptr”
is true on line 205 ?
FWIW: here are the local declarations from the top of SendAllDevicesOnline:
struct ucos__s_event event_msg;
struct low_level_device_struct *LLDEVptr;
struct low_level_sub_class_struct *LLSCptr;
struct high_level_device_struct *HLDEVptr;
unsigned short i;