it doenst matter to runtime what data segment selectors have been
loaded in the segment registers in long mode. we initially load
them with null seletors and then never touch them again.
but the processor *does* check the selectors index when you load
a selector into a segment register!
the reaso
On Sun, Jul 20, 2014 at 3:42 AM, wrote:
> removed the saving and restoring
> of DS/ES/FS/GS segment registers... they have no effect in long mode
Actually FS and GS do work in long mode. Since we don't need them for
TLS, maybe we can do something useful with them.
--
Aram Hăvărneanu
ok, i preserve user R14 and R15 now. also removed the saving and restoring
of DS/ES/FS/GS segment registers... they have no effect in long mode and
there are no 32 bit tasks.
someone write a proof of concept program that communicates with another
process by morsing data on the segment registers by
On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom wrote:
> does anyone have a use case for extern register in user space?
Well Go uses it, but the meaning is different than in the Plan 9
kernel; they reused it for a different storage class.
In Go, there were two external register variables, g and
On Sat Jul 19 10:40:49 EDT 2014, ara...@mgk.ro wrote:
> On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
> wrote:
> > _tos only works when every process has
> > at least one stack always at the same fixed virtual address.
>
> Isn't this always true?
does anyone have a use case for extern registe
On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
wrote:
> _tos only works when every process has
> at least one stack always at the same fixed virtual address.
Isn't this always true?
--
Aram Hăvărneanu
On 19 July 2014 02:57, wrote:
> would it make sense to save and restore the two registers
> on syscall entry/exit, so userspace programs could make use
> of them for per process data?
>
Good question. None of the others need to be saved and restored because
they are defined to be dead on entry t
I don't have any opinion on whether R14 and R15 should be saved, but
the justification posted in the top post seems weak.
The stack is already per-process data. One can use _tos for per-proc
data, just like privalloc(2) does.
--
Aram Hăvărneanu
On Fri Jul 18 22:28:12 EDT 2014, cinap_len...@felloff.net wrote:
> so, we say r14 and r15 arent really special for user programs. and its
> just a c compiler implementation detail that it doesnt allocate these
> registers, but assembly code can freely use them for scratch space
> or whatever. exter
On Fri Jul 18 22:34:43 EDT 2014, cinap_len...@felloff.net wrote:
> isnt that contradicting what you just said?
i didn't think so. restated: you could restore the registers, and that
would be right proper, but it wouldn't make a difference unless you're
using some fancy assembly, or a different co
isnt that contradicting what you just said?
--
cinap
so, we say r14 and r15 arent really special for user programs. and its
just a c compiler implementation detail that it doesnt allocate these
registers, but assembly code can freely use them for scratch space
or whatever. extern register will not work in userspace c programs
because syscalls will tr
On Fri Jul 18 22:05:32 EDT 2014, quans...@quanstro.net wrote:
> On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote:
> > the amd64 compiler reserves R14 and R15 for extern register
> > declarations. these are used by the kernel for the mach
> > and up pointers, but currently are not pre
On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote:
> the amd64 compiler reserves R14 and R15 for extern register
> declarations. these are used by the kernel for the mach
> and up pointers, but currently are not preserved during
> system calls.
>
> would it make sense to save and res
the amd64 compiler reserves R14 and R15 for extern register
declarations. these are used by the kernel for the mach
and up pointers, but currently are not preserved during
system calls.
would it make sense to save and restore the two registers
on syscall entry/exit, so userspace programs could mak
15 matches
Mail list logo
