On 64-bit ‘code-relocation’64-bit virtual address-spaceThe ‘canonical’ addressesOur ‘highcode.s’ demoTwo componentsSubfields of 64-bit address4-level page-mapping tablesDisk-partition’s layout‘ld’ handles 32-bit relocationsassembly commandsLinker commandsInstallation commandsAddition to ‘cs686ipl.s’In-class exerciseOn 64-bit ‘code-relocation’How we can launch a procedure in 64-bit mode that resides in a page-frame at a high address64-bit virtual address-spaceInvalidaddressrangevalidaddressesvalidaddresses0x00000000000000000x00007FFFFFFFFFFF0xFFFFFFFFFFFFFFFF0xFFFF800000000000 ‘non-canonical’ 64-bit addressespositive canonical addressesnegative canonical addresses(128 TeraBytes)(128 TeraBytes)Total number of locations having ‘canonical’ 64-bit addresses is 248 Bytes (= 256 TeraBytes)The ‘canonical’ addresses•In a 64-bit ‘canonical’ virtual address, the uppermost 16-bits are identical to bit 47•The number of distinct virtual addresses actually implemented is 248 (= 256 TB) sign-extension 64-bits48-bitsOur ‘highcode.s’ demo•We have created a demo-program which loads and executes a procedure that will reside at a very high location within the processor’s 64-bit virtual address space•Some aspects of our design were shaped by limitations of our GNU software tools, and by our desire to keep the addressing ‘page-map’ tables as simple as possibleTwo componentsNon-canonicaladdresseshighdraw.bhighcode.b0x00000000000100000xFFFFFFFFC0000000virtual address spaceSubfields of 64-bit address1111111111111111 111111111 111111111 000000000 000000000 000000000000sign-extension (16-bits)index into the page-map level4 table (9-bits) index intopage-directory pointer table (9-bits) index into page-directory (9-bits) index into page-table (9-bits) offset intopage frame (12-bits)4-level page-mapping tablesCR3 page-maplevel4 tablepage directorypointer tables pagedirectories page tablespage framesDisk-partition’s layout/dev/sda40 1 127 128 254 255 …Our ‘cs686ipl.b’ boot-loader goes here (in ‘boot-sector’ of this disk-partition)The ‘highcode.b’ program-component goes hereThe ‘highdraw.b’ program-component goes hereunused‘ld’ handles 32-bit relocations•We use a special linker-script to ‘relocate’ symbolic addresses used in ‘highdraw.s’OUTPUT_FORMAT(binary);SECTIONS {. = 0xFFFFFFFFC0000000;.text : { *(.text) } =0x90909090.data : { *(.data) } = 0x00000000.bss : { *(.bss) } = 0x00000000 }assembly commands•Assemble the ‘highcode.s’ component:$ as highcode.s –o highcode.o•Assemble the ‘highdraw.s’ component:$ as highdraw.s -o highdraw.oLinker commands•Link the ‘highcode.o’ component:$ ld highcode.o -T ldscript -o highcode.b•Assemble the ‘highdraw.s’ component:$ ld highdraw.o -T hiscript -o highdraw.bInstallation commands•Install the ‘highcode.b’ component:$ dd if=highcode.b of=/dev/sda4 seek=1•Assemble the ‘highdraw.s’ component:$ dd if=highdraw.b of=/dev/sda4 seek=128Addition to ‘cs686ipl.s’•We made a small but useful enhancement to our ‘cs686ipl.s’ boot-loader program, so subsequent program components will not need to repeat the search for the starting Logical Block Address of the disk-partition•That block-number is left in register EBX, where the next component can find it•It’s also written to the ROM-BIOS ‘mailbox’In-class exercise•After you have successfully downloaded, assembled, linked, installed, and executed the ‘highcode.s’ demo-program, see if you can modify it so that its ‘highdraw’ code- component will reside at an even higher virtual address, namely: 0xFFFFFFFFFFE00000instead of:
View Full Document
Unlocking...