OSDev.org

Ok, about 3 weeks ago me and my partner ran into this problem with our GetProcAddress() function. It works perfectly in our third stage bootloader but in the HAL driver it fails. It took us awhile (and I got busy with other things so I had to stop for about a week and a half) and I found that strcmp() fails in the HAL.

This is the test I ran in stage3:
This works correctly it sets eax to 0x1337 then halts the system.
Now I commented this out in stage three went to the HAL and recompiled and ran again and the HAL halts with eax=0x2 and ebx=0x1 (error code from GetProcAddress)

I have no idea why at first I thought it was the strcmp() function itself that was failing so I replaced it with a strcmp() that has been proven to work in an older OS of mine and it still fails.

I'm completely stumped the only thing that would make sense is the address space or that it's a DLL instead of an EXE.

strcmp(): Any ideas? :S

Maybe, just maybe, it might be the order of evaluation. I am just trying to think outside the box here.

Normally, boolean operator precedence is from left to right. So the subtraction is executed first, and
second the check if *str2 is zero. Should (in this case) the first evaluation be false, then the second statement
isn't executed. Maybe, in this case, it is the other way around. Maybe *str2 is evaluated first and at the fourth
character it is evaluated false. This means the other statement isn't executed at all and res is still zero.

This, however, would be a very odd situation, but again, I am just trying to think outside the box...

Hope this helps anyway.

Greetz.

hailstorm wrote:Maybe, in this case, it is the other way around. Maybe *str2 is evaluated first and at the fourth
character it is evaluated false. This means the other statement isn't executed at all and res is still zero.

In the C (and C++) language logical expressions are always evaluated from left to right, and short-circuit evaluation rules are applied (meaning that at any point where the result of the complete expression can be determined, evaluation of the rest of the expression is/may be skipped) - contrary to Pascal, where the evaluation order is not specified (although Borland Pascal compilers did use LTR evaluation). I somewhat doubt that this is the cause of the anomaly.

The thread belongs in "General Programming" or better yet, some outside C/C++ forum where you can get considerably better explanation. Once you determined that C is not your problem you are welcome to post. This includes no posting of strcmp code.

geppyfx wrote:The thread belongs in "General Programming" or better yet, some outside C/C++ forum where you can get considerably better explanation. Once you determined that C is not your problem you are welcome to post. This includes no posting of strcmp code.

I don't think C is my problem. I know the problem is with pointer.

Some more tests showed that it returns properly but pointers seem to be messing up. I'm assuming this is because of the changed address space. Putting the strcmp() function inside of the file that calls it (renaming it strcmpp()) also fails. This leads me to believe the pointers are at fault, as for why, I'm not sure.

Whats the problem with GetProcAddress? You just talk about it with no real substance. Also ask yourself the question, Whats different between my third stage bootloader and my hal? Then start debugging.

Yeah sorry about not really explaining GetProcAddress().
It fails because it uses strcmp(). I need it so that drivers can call drivers. (For testing I want the HAL to call the VGA driver)

Now the only difference between stage3 and the HAL is its place in memory which further confirms my suspicion of pointers failing. I still don't see how they could be unless they're pointing to some random place in memory.

AUsername wrote:I'm assuming this is because of the changed address space.

But you haven't posted anything regarding than. This is still c/c++ problems as far as posted code concerned.

Now if you about to post your entire ring0/ring3 switch or task switch inside kernel:
keep in mind that it has to be very small, very well commented, and most importantly illustrate only one single problem where you think there is problem. We must not make assumptions what what you constans mean or state of registers before your code starts.

Do you have paging enabled? Do you have a working printf so that you can output the address of the pointers? Are you encountering a processor fault or is the error routine for GetProcAddress just halting and printing the state?

Try using a simpler strcmp. Also maybe you should look at the asm code of the strcmp function to see if the compiler is messing it up.

frank wrote:Do you have paging enabled?

No.

Do you have a working printf so that you can output the address of the pointers?

Yes, but I need GetProcAddress to work in order to call it from the TVGA driver, and GetProcAddress used strcmp().

Are you encountering a processor fault or is the error routine for GetProcAddress just halting and printing the state?

It halts printing its status. If I remove that it GPFs.

As for the strcmp() part, this one's tested OK. Doesn't help you with your address space issues, but takes away the doubt that it might be the strcmp() implementation.

From PDCLib, more verbose than need be I know:

Solar wrote:As for the strcmp() part, this one's tested OK.

You may want to add && ( *s2 ). Result is undefined if s1 is longer than s2 otherwise.

Are you sure?

^^ trick question...

Oops... nevermind

It's just not obvious at a first glance.

No problem. Actually you had me sweating for a second there.