Strange Function Calls

[fraserjgordon]

When I disassemble my OS kernel, I see that GCC has inserted the following section and function : .gnu.linkonce.t.__i686.get_pc_thunk.bx

There are a few calls to it in my code, but it hangs Bochs when it is called.

The disassembled code for it is this:

mov (%esp, 1), %ebx
ret

What on earth does this function do and how do I get rid of it?
It might have something to so with my -fPIC option, but I don't know.

[Brendan]

Hi,

This code would load the value of EIP (after the call) into EBX:

Code: Select all

     ...
     call __i686.get_pc_thunk.bx
     <-- EIP
     ...


__i686.get_pc_thunk.bx:
     mov (%esp,1), %ebx
     ret

The "mov (%esp,1), %ebx" is confusing, but translates into "load ebx with the value at esp * 1 (or mov ebx,[esp] in Intel syntax). Of course the return address for the call will be on the top of the stack. To me this looks like you're using position independant code or something - otherwise the compiler could produce something like:

Code: Select all

     ...
     mov $L1,%ebx
L1:

Cheers,

Brendan

[Pype.Clicker]

Indeed, when using Position Independent Code, the compiler has to use 'tricks' to learn the *real* offset of data at run time. Indeed, there's no such thing like a "eip-relative data access" in ia-32 instruction set like it exists in PowerPC, Sparc, etc.

That means that the compiler will do

Code: Select all

    call __get_eip_in_ebx
here:
    mov eax,[ebx+(data_address - here)]

when it needs to do

Code: Select all

    mov eax,[data_address]

Fortunately enough, the compiler will also try hard to avoid unnecessary calls to __get_eip_in_ebx by preventing other instructions to access this register.

Now, the real question is "do you really need PIC" ...

[Dreamsmith]

Now, the real question is "do you really need PIC" ...

Indeed, PIC on an Intel processor is supposed to be accomplished by putting the code in its own segments and modifying the segment bases accordingly. Since GCC doesn't support segments, PIC becomes quite a hack. Avoid it if at all possible. Why would you need this in your kernel, anyhow? Usually you only need it for shared libraries. PIC is only needed if the same code is going to be simultaneously located at different addresses in different processes' address spaces.

[fraserjgordon]

Hmm, I used it to get function calls to work when the code segment base address was 0x40000000 (so kernel appeared to start at 0xC0000000). Without this they all gave me a "Prefetch: Running in bogus memory" in Bochs. Is there another way to do this? I tried the virtual address linking thingy with LD but it didn't work (probably 'cause I didn't implement it properly). Is this the way to do it or is another way more effective?

Oh, on another note, I managed to remove the calls by changing the march flag to 386 (GCC is configured for 686). No idea why that happened.

[Dreamsmith]

There are a number of ways to handle it, such as the fun with segment base pointers. Personally, I eschew such madness and instead simply load in two stages. My first stage loads and runs at $100100, enables paging, then "loads" and runs the second stage at $FC000100. "Loads" is quoted because GRUB does all the actual loading, the first stage justs takes the second as a module and relocates it.

[fraserjgordon]

Ah, okay. I never thought of that. Thanks muchly. It sounds like the easiest way to do it. I also hate messing around with segments - why-oh-why couldn't Intel have let us disable it. (Please note that this is a rhetorical question!!!)

[Candy]

I also hate messing around with segments - why-oh-why couldn't Intel have let us disable it. (Please note that this is a rhetorical question!!!)

Until AMD came around it couldn't be answered either. In AMD64 the segment stuff is gone. You don't have to make it rhetorical anymore, it's found an answer.

[fraserjgordon]

WOOHOO! Now, to scrape up enough money to replace my 32-bit 3GHz HT Pentium 4 and mobo with a (probably slower, considering my finances) 64-bit AMD.

Do the 64-bit Intels still have segmentation in "long" mode?

[Candy]

WOOHOO! Now, to scrape up enough money to replace my 32-bit 3GHz HT Pentium 4 and mobo with a (probably slower, considering my finances) 64-bit AMD.

Do the 64-bit Intels still have segmentation in "long" mode?

Not exactly, but they do still have forced stack swapping (SYSENTER versus SYSCALL). Also, there are 4 other differences, of which I don't know exactly what they were.

PS: sell your p4-HT and try to get a good price, you can probably get away with a nice S754 athlon64 with a nice speed (3800+ or something). How often did you actually use up to 60% of your cpu?

[srg]

An Athlon 64 of at least 3000+ vs the 3GHz P4 is no contest, the Athlon 64 crushes it.

srg

[fraserjgordon]

Oooh, fast. Actually, considering the HT technology and WinXP Home, the processor usage can't go over 50% when programs are running on both "processors". So it never goes over 60%

The problem is that the PC is still under warranty and as its a family PC my parents won't exactly want me invalidating it (even though I could fix more problems than the supplier).

What kind of price could you sell the P4+mobo for anyway?

[Candy]

on gathering.tweakers.net there's a list of second-hand to-expect prices

Your proc (without HT) lists for 140 euros, probably around 160-180 with

your mainboard might go up to 50 euros, or up to 100 if it's a good one (have seen it).

Then, you got around 190-280 euro's for a new mobo plus proc, which is slightly short of a good amd64. picking a random dutch computer shop: 3200+ for 305 euro, Asus K8V for 141 euro, total of 346 euro. That's between 66 and 156 euro short, but imo if you want to do 64-bit osdev, not much.

Wouldn't do it though, HT's are like MP's, also offers a nice test plat.

[fraserjgordon]

Yup. I've got two other PCs in the house that I use for testing and they are only 32-bits (one is an Intel 386 @ 120MHz, the other an AMD Athlon @ 1GHz). With those two and my P4 I have a nice range.

Back to the original topic, I finally got the damn paging/segmentation thing working by messing around with my linker script and getting the assembler to do some maths involving 0xC0000000. Oh, not forgetting lots of use of the Bochs debugger

At least it works. I can finally do something of worth now.