App compilation: wrong string literal addresses

[Robert]

Hi!

I compiled some apps for my OS in simple gcc.
Did not use any special switches, only -m32.
But the assembled code tries to find my string literals and some global variables on the address <normal linear addr> + 128MB.
Do you have any idea how to solve this?

Thanks in advance!

A little example:
PrintMessage("heyho");
compiled to
mov [esp], 0x8000345
call <func addr>

instead of
mov [esp], 0x345
call <func addr>

[iansjack]

What is the load address of the program?

[Robert]

What is the load address of the program?

0x700000 (7M, physical addressing)

Inside the segment the binary loaded to 0x0,
entry address comes from ELF header.

So if I use only local variables, even for the string literals -> everything works fine. But not so elegant...

[iansjack]

Then you wouldn't expect the string to be located at 0x345, would you?

[Robert]

Then you wouldn't expect the string to be located at 0x345, would you?

The relative address (inside the segment is 0x345.
The string is there. But the generated assembly code has a wrong relative address.


The point is that the compiled code has a wrong address for the string literals.
It searches them in a wrong area, resulting empty outputs and potentially GPFs.

[bzt]

Did not use any special switches, only -m32.

That's the problem. You've used "simple gcc", by that I guess you mean the host compiler, and you haven't used any linker scripts. That means your application is going to be compiled for your HOST operating system, and not for your TARGET operating system.

But the assembled code tries to find my string literals and some global variables on the address <normal linear addr> + 128MB.
Do you have any idea how to solve this?

Use a cross-compiler and a linker script.

If you don't do anything special, then you might use your host compiler and linker with -ffreestanding, -fnostdinc -fnostdlib -fnostartfiles switches, and adding your OS' crt0.o and your target OS' libc manually to the command line arguments. But that's not guaranteed to work, you should use a cross-compiler and a linker script to specify the addresses instead (out wiki also has a page on linker scripts, but that's primarily about linking the kernel, not userspace apps).

Cheers,
bzt

[iansjack]

The relative address (inside the segment is 0x345.
The string is there. But the generated assembly code has a wrong relative address.

But the code uses an absolute address rather than a relative one. Or are you saying that you have set up a segment with base address 0x700000?

Also, does your program loader load the .rodata segment as well as the code?

[Robert]

The relative address (inside the segment is 0x345.
The string is there. But the generated assembly code has a wrong relative address.

But the code uses an absolute address rather than a relative one. Or are you saying that you have set up a segment with base address 0x700000?

Also, does your program loader load the .rodata segment as well as the code?

Segmented memory model, application has cs, ds, ss on same address: 0x700000. ELF binary loaded to 0 offset, entry point called correctly. Although compiled on host without cross-compiler,
worked well if I did not use nameless string literals, because it used a custom stdlib.
Have no linker script. .rodata isn't handled distinctly.

[Robert]

Then you wouldn't expect the string to be located at 0x345, would you?

Inside the segment it's there. The problem is the address given to registers does not point to the string. It has a huge constant added (for all of them the same): 0x8000000 as I remember.

I assume that something messed up in the compiler.

[iansjack]

I'm, confused. An elf file is not a simple binary. Your program loader has to load the read-only data segment at the appropriate address. If you're not loading it you're not loading your string constants.

I'm also confused about your segment usage. You don't say what host OS you are compiling on, but if it's any of the popular ones then it uses a memory model where all the segments are zero-based. 0x345 will not be a valid address for data. Your OS might use segments based at 0x700000, but the OS that you compiled on (and hence the program that it produced) doesn't. Any absolute memory references in it will be those that the host OS expects, not your OS.

The compiler didn't mess up.