Memory pools and alignment

[Francesco S. Carta]

The EFLAGS register is process specific. The OS kernel keeps track of the
value it should have for each process. There are (virtually?) no registers
that a process can set that could have any impact on annother process,
baring a completely broken kernel.

The assembly shown loads the EFLAGS register into the ESP register, nors the
ESP register in place with the value 0x40000 in place, and then loads the
new value into the EFLAGS register.

Thanks a lot for these details Joe - now I also realized that it
wouldn't make much sense to allow such a system-wide change, wrt your
mention of the "broken kernel"

Have good time,
Francesco

 

[Maxim Yegorushkin]

On 13/10/09 08:54, James Kanze wrote:

[]

The implementation is allowed to pad pretty much however it
wants. I think it's even "unspecified", rather than
"implementation defined", so the implementation is not even
required to document it (but I could be wrong about that). Most
Intel implementations do pad for alignment (with some variance
concerning long double: 10, 12 or 16 bytes total, depending on
who wrote the compiler, with the additional bytes often being
part of the type, rather than padding).

The alignment and size of long double must be a part of the platform C
ABI. If it was not,

long double x;
scanf("%Lf", &x);

Would not be portable (provided the same C library is used).

There can be no variance in the size and alignment of long double on the
same platform, otherwise C libraries compiled with different compilers
would not be binary compatible.

 

[James Kanze]

On 13/10/09 08:54, James Kanze wrote:

[]

The implementation is allowed to pad pretty much however it
wants. I think it's even "unspecified", rather than
"implementation defined", so the implementation is not even
required to document it (but I could be wrong about that).
Most Intel implementations do pad for alignment (with some
variance concerning long double: 10, 12 or 16 bytes total,
depending on who wrote the compiler, with the additional
bytes often being part of the type, rather than padding).

The alignment and size of long double must be a part of the
platform C ABI. If it was not,

long double x;
scanf("%Lf", &x);

Would not be portable (provided the same C library is used).

There can be no variance in the size and alignment of long
double on the same platform, otherwise C libraries compiled
with different compilers would not be binary compatible.

Yes and no. It's a good point, but in the end, scanf isn't part
of the system ABI, so you could potentially have a different C
compilers using a different C ABI. (I don't think that there
are any system functions using long double, at least on most
systems.) In practice, however, you're probably right; most
platforms will have some sort of well defined C ABI, which goes
beyond just the system functions. (Posix requires it; it
doesn't distinguish between system functions and the C library.)