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.

"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 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).

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.

Walter wrote:
> "Mike Wynn" <mike@l8night.co.uk> wrote in message
> news:bjl7a8$2a2n$1@digitaldaemon.com...
> 
>>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>.

so no 48 bit far calls ?

> 
> 
>>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.
> 

on gcc you have __attribute__((section("foo"))) how do I do that in D ?

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjlnh0$3111$1@digitaldaemon.com...
> Walter wrote:
> > "Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjl7a8$2a2n$1@digitaldaemon.com...
> >>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>.
> so no 48 bit far calls ?

Right. You'd have to do a shim for them in assembly.

> > 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 ?

At the moment, run patchobj.

> 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.

"Serge K" <skarebo@programmer.net> wrote in message news:bjotnm$1cn8$1@digitaldaemon.com...
> > 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.

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.

Walter wrote:
> "Serge K" <skarebo@programmer.net> wrote in message
> news:bjotnm$1cn8$1@digitaldaemon.com...
> 
>>>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.
> 
> 
> 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.
> 

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.