to relocate or not to relocate ?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:
Contact Solar

Re:to relocate or not to relocate ?

Post by Solar »

Pype.Clicker wrote: This sounds dangerous as the OS would have no way to prevent the application from copying the "lib pointer" somewhere...
Well, you could just set up rules for the proper use of libs by applications. It worked quite well for AmigaOS programmers, who were not allowed to cache lib base addresses either...
(think about the lib returning a pointer to an internal static buffer -- this is crappy but done very often :-/ )
You can protect yourself against Murphy, but not Machiavelli. Set up rules, and just make sure that violating those rules only hurts the violating process.
Every good solution is obvious once you've found it.
Top
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:to relocate or not to relocate ?

Post by Candy »

I've been reading through the AMD64 manuals, and I've stumbled across a very plain logic, that would require writing a new compiler. Yet, imo, it's very elegant

X86 cpu's have the DS segment for data, the ES as extra segment, and there's even an FS and a GS segment that are usually not even used. If the compiler would put all static stuff of a library in the GS segment (or just explain in the object format how large it should be etc), and put the per-program data above it, it could put the process-specific data in the DS segment (which is global as usual, along with static data) or in FS on explicit request, where the thread-global variables would be kept. This all combined would allow a lot better memory usage if I'm not mistaking.

Modifying pointers a little bit to 34 bit structures would allow this too. The DS and SS are still mapped to a flat memory, but ES/FS/GS to different bits. The first two bits would indicate in which segment to write (DS/ES/FS/GS) so pointers would still function as always. In C++ you could easily implement this with some weird structure.

Sidenote for people also thinking about AMD64: Since amd only allows up to 56 bits of pointers, and requires the rest to be canonical, abuse the top 2 bits for the segment in the 64-bit pointers and and it with 0x3FFF FFFF FFFF FFFF to undo that before using it as normal pointer in the code.

As for loading libs in the usual environment, why not allocate 3 3/4 G of the address space to the process, and allocate for libraries (and shared memory areas) from the top of the address space? This would allow up to 3.5G (assuming you need at least some libraries to run) for the people daring enough to make the computer dedicated, and up to 1 3/4 G of space for shared memory & libs for normal computers. Solution seems to fit in both environments :)

As advantage for the first scheme (that I'm planning on using) is that copying the library pointer to user space (or having a library allow that) is VERY easy to trace to a library (just dump the address space allocation on that point to a disk and check the pointer) so bad libraries could very easily be traced to the creator (upon which the OS cannot be held responsible anymore, because it can irrevokably prove it wasn't at fault).

Grtz, Candy
Top
Post Reply

Return to “OS Development”