OSDev.org

BASICFreak wrote:Every char array you have points to .got

The only way I have successfully got a PIE/PIC (binary) to work was without any constants - all data must be dynamically initialized or you must use an output format that allows the .got section

You could always try adding the .got section to the ld script - IIRC it failed too...

BTW try the -shared flag instead of -fPIE as it does not produce the .got section (At least on my ELF loader)



Happy hacking,

B!

Thanks. Your post has been about the most helpful so far.

BASICFreak wrote:Every char array you have points to .got

That solved the problem.

For the schoolteachers among us, here is the explanation as to why it solves the problem:

• the string is stored in the .data segment
• .got stores a list of pointers into the .data segment to facilitate easier relocation and is initialised by the loader as the loader decides where the .data segment is loaded in relation to the executable segment
• therefore to load a string defined in the source code we need to get the address from .got

Why the string can't just be inserted in-line with the executable segment at the end of the code I don't know, but that's another matter. Perhaps there's a way to write the linker script so that the .data segment is placed directly at the end of the executable segment, and then eliminate the .got and use relative pointers? That sounds like it would work, but somehow I think it will need a whole new compiler as gcc is starting to feel very inflexible...

onlyonemac wrote:Why the string can't just be inserted in-line with the executable segment at the end of the code I don't know, but that's another matter. Perhaps there's a way to write the linker script so that the .data segment is placed directly at the end of the executable segment, and then eliminate the .got and use relative pointers? That sounds like it would work, but somehow I think it will need a whole new compiler as gcc is starting to feel very inflexible...

The string cannot be stored due to there being NO relative addressing for memory access (on the x86 at-least) only for EXEC (Jumps and Calls). It's not an issue with GCC it's an issue with the CPU.

Of course the x86_64 does allow relative addressing, which makes life a whole lot simpler. Yet another reason to use the 64-bit capabilities of modern processors.

onlyonemac wrote:perhaps you should stop mentioning ELF files.

Difficult. The object files that you produce with the C compiler are ELF files, so it's important to understand them when you try to link them to produce a flat binary.

now we have to do the whole paging thing

You are correct. Paging has a lot to recommend it. It looks to me as if, again, you are creating a lot of big problems by trying to avoid the small problem of learning how to use paging.

Sorry if all this seems like "teaching", but the best way for you to achieve what you want is if you learn for yourself what the problems are rather than just asking for solutions.

iansjack wrote:Of course the x86_64 does allow relative addressing, which makes life a whole lot simpler. Yet another reason to use the 64-bit capabilities of modern processors.

Yes, but then the issue is GCC - as I have read from many different sources that GCC still doesn't use relative addressing. I have not personally tried so take that with a grain of salt - plus I do not want to look-up a source...

BASICFreak wrote:I have read from many different sources that GCC still doesn't use relative addressing.

Your sources are incorrect. I did a quick test compile of a simple variant of this program producing 32- and 64-bit object files, both with and without -fPIE. In the 64-bit case, with the -fPIE switch, the result contained position-independent addressing of the string as opposed to the hoops and loops of the 32-bit case.

iansjack wrote:

BASICFreak wrote:I have read from many different sources that GCC still doesn't use relative addressing.

Your sources are incorrect. I did a quick test compile of a simple variant of this program producing 32- and 64-bit object files, both with and without -fPIE. In the 64-bit case, with the -fPIE switch, the result contained position-independent addressing of the string as opposed to the hoops and loops of the 32-bit case.

Cool, I'm actually glad my sources are wrong - as I will be needing this functionality soon.

iansjack wrote:Paging has a lot to recommend it. It looks to me as if, again, you are creating a lot of big problems by trying to avoid the small problem of learning how to use paging.

I do actually know how to use paging, have successfully enabled paging, and have drafted a page allocator. But paging didn't fit with the design of my operating system.

Yes, maybe my design is bad, but that's for me to decide. It's an experiment, and I seriously doubt that the absence of paging is going to make the difference between the operating system working perfectly and the operating system not working at all, especially when I have it all planned out as a set of data structures and pseudocode routines in my head.

That's fine - as long as you are aware that all design decision impose certain constraints upon the operating system. Personally, I can't think of a good reason to forgo the advantages of paging, but if it suits you to do so then that is your choice to make. But, as you see, it does lead to difficulties elsewhere.

iansjack wrote:Personally, I can't think of a good reason to forgo the advantages of paging, but if it suits you to do so then that is your choice to make. But, as you see, it does lead to difficulties elsewhere.

Likewise, the use of paging can lead to difficulties with certain designs of operating systems.

onlyonemac wrote:

iansjack wrote:Personally, I can't think of a good reason to forgo the advantages of paging, but if it suits you to do so then that is your choice to make. But, as you see, it does lead to difficulties elsewhere.

Likewise, the use of paging can lead to difficulties with certain designs of operating systems.

For example?

iansjack wrote:

onlyonemac wrote:

iansjack wrote:Personally, I can't think of a good reason to forgo the advantages of paging, but if it suits you to do so then that is your choice to make. But, as you see, it does lead to difficulties elsewhere.

Likewise, the use of paging can lead to difficulties with certain designs of operating systems.

For example?

Every time I switch from one code module to another, I will have to enter a new page context, causing some performance hit - and code modules are small and numerous. Then every object which the code module wants to access needs to be mapped into the code module's page context, and to make things really interesting it will need to be mapped to exactly the same place for different code modules, otherwise object pointers passed from one module to another would be invalid (a major issue, considering that the main way in which the operating system works is by passing object pointers around). So you don't get many - if any - benefits from using paging but have all the pain of managing multiple page contexts.

Every time I switch from one code module to another, I will have to enter a new page context, causing some performance hit - and code modules are small and numerous. Then every object which the code module wants to access needs to be mapped into the code module's page context, and to make things really interesting it will need to be mapped to exactly the same place for different code modules, otherwise object pointers passed from one module to another would be invalid (a major issue, considering that the main way in which the operating system works is by passing object pointers around). So you don't get many - if any - benefits from using paging but have all the pain of managing multiple page contexts.

This sounds tricky and problematic to me.

One of my OS's, I use a 1:1 page mapping using 1GB pages, works just fine for what it is needed for.

I am guessing that as you progress through your OS your thoughts might change?

That's fair enough. You just have to add the relocation information to your custom executable format and ensure that your loader does the necessary fixups.