Article View: comp.lang.asm.x86
Article #187Re: 32bit Assembler ( figureing out relocations )
From: Kazimir Kylheku
Date: Mon, 16 Jan 1995 22:14
Date: Mon, 16 Jan 1995 22:14
100 lines
6312 bytes
6312 bytes
In article <3f9kib$36o@flood.xnet.com>, Erica A. Ramsey <lajade@xnet.com> wrote: >Hello, I want to write an assembler. I notice that dos .exe files have >relocation tables in them. This allows a module to relocated at load time. >Well, I recently looked inside a 32bit protected mode program and they have >relocation tables too. Well, i want to create a 32bit assembler with C >extentions, and I guess, as I can see now, i'll have to maintain a relocation >table too. The relocation table has address of items to be relocated at >load time. > >I really don't see why a relocation table is necessary for 32bit protected >mode or even dos programs!!! the offsets within the modules themselves >don't change, regardless of the address the module was loaded at!!! You are right. Relocation tables date back to the 1960's - before many computers had virtual memory. In protected mode, you can run each program at the same logical address, either through segmentation or through paging. >The only use of relocation tables for dos .exe files, I think, is that if >one is using far pointers. The same for 32bit protected mode programs, >relocation is only needed if the program uses 48bit far pointers; remember, >in 32bit protected mode a far pointer is 16bit selector plus 32bit offset. >If I say ahead time that one cannot use far pointers then I should be >fine; ie, I will not need relocation tables. Or I could be wrong, I'm so >confused help! No, 48 bit far pointers are not used in the same way in the 386 as in the 8086. Keep in mind that segments are *required* in the 8086 to reach the entire address space, whereas the physical address space in the 386 is entirely addressable by an offset. >How do I know which items should be relocatable ? 'call' instructions You are also forgetting that you can achieve segment relocation by changing the values of the descriptors. The selectors shouldn't have to change. A program can contain a statement like "CALL 0001:000001FD". This simply means call the logical address 1FD within whatever segment is referenced by selector 0001. Change the descriptor for 0001, and you point the segment reference somewhere else, without changing the code. It's not necessary to segment your code or your data structures, however - it only makes things more complicated than they need to be. With a simple 4GB flat memory model you can address and manage all of your memory just as well. As an example, the HP-UX operating system (for HPPA RISC machines) divides the virtual address space into 1-GB quadrants. Code goes into quadrant 1. Data into quadrant 2. Shared libraries go into quadrant 3 (I think). Most likely, the OS code can be seen in quadrant 4. It's rather a neat division. When the CPU is switched from one process to another, the OS switchs to a different page table that points to different code and data, but keeps the same aliases for shared references, such as the libraries or OS code. >shouldn't need to be relocated because 'call' instructions are relative >from pc counter; correct? conditional jumps shouldn't need to be relocated >because they are also relative from pc counter. But, jmp instructs >and variables would have to be relocatable because they are absolute >addresses in some cases and in the other cases they need to relocated >because the datum of data segment has changed. is this correct? gimme >more help! please. Again, this is true of the 8086, but in the 386 protected mode, you simply update the segment descriptor tables, and leave the selectors alone. >Is a link phase really necessary ? Can't I just create exe modules? I >don't plan to have libraries or anything. If all you want is to take a single program file and produce machine code, you can have your compiler/assembler produce the binary image directly. If you restrict yourself thus, the link-edit phase can be dispensed with. I don't think that the EXE format can support protected mode programs. You can write a a DOS extender as an EXE file, and have the extender set up the machine for running your 32-bit protected mode program. >I have gnu assembler source from binutils. does anyone have any >experience porting gas to dos ? Yes, DJ Delorie does. Have you looked that the DJGPP package? It's a port of the GNU development tools to DOS and comes with an extender that sets up a protected-mode environment for your executables. It automatically sets up demand paging, so you can easily run programs that outstrip your physical memory. The way it's set up is that you run a program called GO32.EXE, which sets up the environment for your executable and then loads & runs it (actually it page-faults it in on demand). There are various options for combining GO32 with the a.out executable, so that the user can run a simple .EXE file instead of typing "GO32 <program>" Regardless of the invocation method, the .EXE headers only affect the GO32 extender, not the image of your a.out executable. GO32 executables always start at the same logical address, thus absolute references are not a problem.
Technical Details
Message-ID:
<3fer4rINN25u@keats.ugrad.cs.ubc.ca>Path:
arc1-ca.pugleaf.net!nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!howland.reston.ans.net! gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!cs.ubc.ca!keats.ugrad.cs.ubc.ca!not-for-mailReferences:
<3f9kib$36o@flood.xnet.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11318c,14c198d00592d0c8 X-Google-Attributes: gid11318c,public X-Google-Thread: 10f6aa,14c198d00592d0c8 X-Google-Attributes: gid10f6aa,public X-Google-Thread: 110292,14c198d00592d0c8 X-Google-Attributes: gid110292,public X-Google-Thread: 102bfa,14c198d00592d0c8 X-Google-Attributes: gid102bfa,public X-Google-Thread: 114917,14c198d00592d0c8 X-Google-Attributes: gid114917,public X-Google-ArrivalTime: 1995-01-17 00:54:30 PST Path: arc1-ca.pugleaf.net!nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!howland.reston.ans.net! gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!cs.ubc.ca!keats.ugrad.cs.ubc.ca!not-for-mail From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Newsgroups: comp.lang.asm.x86,comp.sys.intel,alt.msdos.programmer,comp.os.msdos.programmer,gnu.gcc.help Subject: Re: 32bit Assembler ( figureing out relocations ) Date: 16 Jan 1995 14:14:51 -0800 Organization: Computer Science, University of B.C., Vancouver, B.C., Canada Lines: 103 Message-ID: <3fer4rINN25u@keats.ugrad.cs.ubc.ca> References: <3f9kib$36o@flood.xnet.com> NNTP-Posting-Host: keats.ugrad.cs.ubc.ca