D - D memory space assumptions ?
- Mike Wynn (33/33) Sep 09 2003 Walter,
- Walter (10/43) Sep 09 2003 The short answer is exactly the same assumptions that the associated C
Walter, what assumptions does the D compiler make about the memory space ? I assume currently it is A) flat 32 bit B) on x86 CS, DS, ES and SS if not the same map to the same address space cs:[0] == ds:[0] == es[0] == ss:[0] C) no support for "far" (with segment) or just longer than usual pointers. D) threads can see each other stacks. E) code is readable (and consts are in code) from an application programmers point of view that is great, I have been thinking of trying to use the protection the x86 offers to do the following. cs: code seg (exe only) ds: data seg (read/write no execute) es: const seg (read only) ss: stack seg (read/write) only current thread can see it. but each would be 0 based so pointers to automatics would not be passable as params (solveable if stack structs/arrays could be forced into the heap). (inout/out know that its an ss not ds based offset) although I'm rapidly comming to the conclusion that x86 segments are pointless (I want to create a protected range). do you intend to add support for "far" calls or calls into a different "space" (and ways to declare that a function is in a specific "space"), for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb, the compiler would need to know which instruction set has been used to get the address correct (thumb has bit 0 set). do you intend to support named "segments" to allow data/code to be put into different places. allowing statics to be allocated in name segments (on linux/win32 they would just be sorted together then put into data/bss as requires) named segments either data (0's stored in image if not initialised) or bss (initialisers not allowed) or const (rom/code). not all arch's have contigious address spaces and some have fast/slow ram/rom areas so placement can be important.
Sep 09 2003
"Mike Wynn" <mike l8night.co.uk> wrote in message news:bjl7a8$2a2n$1 digitaldaemon.com...Walter, what assumptions does the D compiler make about the memory space ? I assume currently it is A) flat 32 bit B) on x86 CS, DS, ES and SS if not the same map to the same address space cs:[0] == ds:[0] == es[0] == ss:[0] C) no support for "far" (with segment) or just longer than usual pointers. D) threads can see each other stacks. E) code is readable (and consts are in code)The short answer is exactly the same assumptions that the associated C compiler makes - DMC for Win32, and gcc for Linux. A..E are true, except that consts go into the data segment, not code segment.from an application programmers point of view that is great, I have been thinking of trying to use the protection the x86 offers to do thefollowing.cs: code seg (exe only) ds: data seg (read/write no execute) es: const seg (read only) ss: stack seg (read/write) only current thread can see it. but each would be 0 based so pointers to automatics would not be passable as params (solveable if stack structs/arrays could be forced into the heap). (inout/out know that its an ss not ds based offset) although I'm rapidly comming to the conclusion that x86 segments are pointless (I want to create a protected range).I don't really understand why Win32 doesn't turn off the "execute" bit for the stack. That would put the kibosh on most buffer overflow exploits.do you intend to add support for "far" calls or calls into a different "space" (and ways to declare that a function is in a specific "space"), for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb, the compiler would need to know which instruction set has been used to get the address correct (thumb has bit 0 set).No. I left all that far call stuff back in the dos world <g>.do you intend to support named "segments" to allow data/code to be put into different places. allowing statics to be allocated in name segments (on linux/win32 they would just be sorted together then put into data/bss as requires) named segments either data (0's stored in image if not initialised) or bss (initialisers not allowed) or const (rom/code). not all arch's have contigious address spaces and some have fast/slow ram/rom areas so placement can be important.At the moment, not any more than you can with C compilers.
Sep 09 2003
Walter wrote:"Mike Wynn" <mike l8night.co.uk> wrote in message news:bjl7a8$2a2n$1 digitaldaemon.com...so no 48 bit far calls ?do you intend to add support for "far" calls or calls into a different "space" (and ways to declare that a function is in a specific "space"), for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb, the compiler would need to know which instruction set has been used to get the address correct (thumb has bit 0 set).No. I left all that far call stuff back in the dos world <g>.on gcc you have __attribute__((section("foo"))) how do I do that in D ?do you intend to support named "segments" to allow data/code to be put into different places. allowing statics to be allocated in name segments (on linux/win32 they would just be sorted together then put into data/bss as requires) named segments either data (0's stored in image if not initialised) or bss (initialisers not allowed) or const (rom/code). not all arch's have contigious address spaces and some have fast/slow ram/rom areas so placement can be important.At the moment, not any more than you can with C compilers.
Sep 09 2003
"Walter" <walter digitalmars.com> "Mike Wynn" <mike l8night.co.uk> wrote in message news:bjlnh0$3111$1 digitaldaemon.com...Walter wrote:Right. You'd have to do a shim for them in assembly."Mike Wynn" <mike l8night.co.uk> wrote in message news:bjl7a8$2a2n$1 digitaldaemon.com...so no 48 bit far calls ?do you intend to add support for "far" calls or calls into a different "space" (and ways to declare that a function is in a specific "space"), for instance on Arm7T/Arm9T you have two instruction sets ARM and Thumb, the compiler would need to know which instruction set has been used to get the address correct (thumb has bit 0 set).No. I left all that far call stuff back in the dos world <g>.At the moment, run patchobj.At the moment, not any more than you can with C compilers.on gcc you have __attribute__((section("foo"))) how do I do that in D ?
Sep 09 2003
I don't really understand why Win32 doesn't turn off the "execute" bit for the stack. That would put the kibosh on most buffer overflow exploits.The tricks with stack works by overwriting return address, but this address is still for the location in the CS segment - disabling code execution for it is not a good idea... ;-) IA32 has an "execute" bit for segments only, there is no way to control it per page.
Sep 10 2003
"Serge K" <skarebo programmer.net> wrote in message news:bjotnm$1cn8$1 digitaldaemon.com...forI don't really understand why Win32 doesn't turn off the "execute" bitaddressthe stack. That would put the kibosh on most buffer overflow exploits.The tricks with stack works by overwriting return address, but thisis still for the location in the CS segment - disabling code execution for it is not a good idea... ;-) IA32 has an "execute" bit for segments only, there is no way to control it per page.The way to do it is to not have the CS segment contain the stack area. It is possible to have CS and SS have different selectors mapping over each other, but with different sizes.
Sep 10 2003
Walter wrote:"Serge K" <skarebo programmer.net> wrote in message news:bjotnm$1cn8$1 digitaldaemon.com...D/C/C++ make the assumption that the address of a stack object is in the "data segment" and that two threads can see each others stacks. so you can not gain any benifit from SS it has to be DS because the x86 segmenting only allow 0..n to remap to m..(n+m) not a...b to map to a+m..b+m also it is allowable for threads to write in each others stacks auto int a[10]; you can pass &a[n] to another thread. it is true that not having the stack or data space visible via the cs would solve the problem where the return address is overwritten to branch into code that has been layed onto the stack (usual buffer overrun method), it does not stop you launching the eip into hyperspace, or jumping back N functions with a valid return value thus avoiding some check or other (patch rtn+oldebp) is done right you jump back to a leave rtn so both esp and ebp can be set to whatevery you like. solution is to only use the hardware stack for rtn address (maybe save/restore of registers) and use ebx instead of esp thus you can have a stack in the heap.forI don't really understand why Win32 doesn't turn off the "execute" bitaddressthe stack. That would put the kibosh on most buffer overflow exploits.The tricks with stack works by overwriting return address, but thisis still for the location in the CS segment - disabling code execution for it is not a good idea... ;-) IA32 has an "execute" bit for segments only, there is no way to control it per page.The way to do it is to not have the CS segment contain the stack area. It is possible to have CS and SS have different selectors mapping over each other, but with different sizes.
Sep 11 2003