OSDev.org

Apologies for the stupid question, but I can't seem to find a solution to this... I've got a cross compiler to i386-elf-pc built, and I'm compiling with -O0. This configuration has never given me any trouble with my kernel at all, however.. When building my userland test cases, it's rearranging things terribly. i.e. I have a loop that waits for an incoming connection, saves the descriptor, then listens for a message, and is supposed to send a reply when said message arrives. However, it is getting the incoming connection, saying it's waiting for the message, receiving the message (which clears the queue), THEN saying, erroneously, that it's waiting for the incoming connection, and then finally moving to the "waiting for message loop", and not ever sending the reply because the queue has already cleared by the premature message checking..
I'm not really sure what's going on with this.. Isn't it supposed to not reorder/refactor loops unless optimization is turned on? And why would it execute my receive message system call outside of the loop, and then still execute the loop later?
*sigh* Sorry for the rambling nature of this message. It's late, and I'm really not understanding this..

You might want to disassemble the output and verify that it is in fact coming out right. If it is, then you may have a bug elsewhere.

Strange. I disassembled it, and with a cursory glance, it seems to be in the right order, but it does not behave so. I'm double checking exactly what's happening with my loops now..

Well, then its time to stop blaming the compiler (It's always right!), and start blaming your code.

Understood. I wasn't meaning to blame the compiler, I was more wondering if there was a common mistake I was making and missing in my searches.. The odd thing is that much of the code is shared between the client and server tests, and the client side works properly..

Combuster wrote:Well, then its time to stop blaming the compiler (It's always right!), and start blaming your code.

The compiler may always be right, but that doesnt mean its doing what you want it to do, just what you told it to do

Make sure you use volatile correctly. I've seen errors where people don't use volatile correctly and then blame the compiler when it changes the orders of loads and stores to optimize.

dude101 wrote:Make sure you use volatile correctly. I've seen errors where people don't use volatile correctly and then blame the compiler when it changes the orders of loads and stores to optimize.

yea, volatile and firends get interesting with pointers..
iirc volatile char * and char volatile* are completely different things

The usual way I go when I think the compiler produces code that I didn't expect is to break down the steps.

1) Do the preprocessor produce the expected result?
2) Do the compiler produce the expected result (check the assembler code)?
3) Does the program run the generated code?

If you've disassembled the code and it's as you expect then you've probably checked all these, but did you disassemble the object file, executable or even the code after loading it?

earlz wrote:iirc volatile char * and char volatile* are completely different things

IIRC, no.

My advice: Always use qualifiers (const, volatile) postfix. That way you're always correct. (Doesn't work the other way around.)

Thank you all for the advice. I did end up getting the bug fixed, and my impromptu userspace lib is working as expected now.

earlz wrote:iirc volatile char * and char volatile* are completely different things

No they aren't, but volatile char * and char *volatile are. The difference is subtle, but the first is a pointer to volatile char, the latter is a volatile pointer to char.

Combuster wrote:... stop blaming the compiler (It's always right!)

It's not always right. It's just about always right. Always keep in the back of your head that it may be wrong - just narrow down the test case sufficiently. I've reported & gotten fixed two definite compiler bugs and added one warning (which will be in GCC from 4.6 and on). Microsoft tends to admit that it's a bug but that old code relies on it so they won't fix it.

Long story short: Search for alternative explanations for at least a month unless you're on the fringes of a language. The bugs I found were (1) incorrect handling of overloads based on the volatile/constness of a member function pointer argument crashing the compiler and (2) GCC 4.3.0 which handled X<Y<void()>> without space incorrectly (and it was the first version that claimed to do that). If you're doing something simpler, don't bet on finding a bug.

Hobbes wrote:

earlz wrote:iirc volatile char * and char volatile* are completely different things

No they aren't, but volatile char * and char *volatile are. The difference is subtle, but the first is a pointer to volatile char, the latter is a volatile pointer to char.

The example we use for this in the C++ course we teach is (as a member function)

const(1) char const(2) * const(3) func(const(4) char const(5) * const(6)) const(7) {

}

OF these 7 consts, 5 locations are useful and do something. Two are dupes.

(1) and (2) are both making the char pointed to const. (3) makes the pointer itself (but not what it points to!) const. (4) and (5) do that for the argument, making the pointed-to const. (6) makes the argument itself const, which is usually pointless (as it's a copy anyway). (7) makes the function const (literally: it makes the implicit this pointer into a const pointer).

Most people recommend leaving out (1) and (4) and reading the type from right to left. So,

char const * volatile

would be a volatile pointer to a const char. Which is correct!

inx wrote:Thank you all for the advice. I did end up getting the bug fixed, and my impromptu userspace lib is working as expected now.

Most importantly, what was it?

The more expected place the errors are is in the code.

But the compilers are not infallible. Even an CPU needs his microcode updates.

Patience, Inx. If you feel stuck with the problem, just give yourself a break. This often helps me.