On Wed, Aug 26, 2015 at 8:13 PM, Brian Gerst wrote:
> On Wed, Aug 26, 2015 at 1:10 PM, Andy Lutomirski wrote:
>> On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst wrote:
>> Thing 2: vdso compilation with binutils that doesn't support .cfi
>> directives
>>
>> Userspace debuggers
On Wed, Aug 26, 2015 at 1:10 PM, Andy Lutomirski wrote:
> On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst wrote:
> Thing 2: vdso compilation with binutils that doesn't support .cfi
> directives
>
> Userspace debuggers really like having the vdso properly
> CFI-annotated, and
On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst wrote:
Thing 2: vdso compilation with binutils that doesn't support .cfi
directives
Userspace debuggers really like having the vdso properly
CFI-annotated, and the 32-bit fast syscall entries are annotatied
manually in
On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst brge...@gmail.com wrote:
Thing 2: vdso compilation with binutils that doesn't support .cfi
directives
Userspace debuggers really like having the vdso properly
CFI-annotated, and the 32-bit fast syscall entries are annotatied
manually in
On Wed, Aug 26, 2015 at 1:10 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst brge...@gmail.com wrote:
Thing 2: vdso compilation with binutils that doesn't support .cfi
directives
Userspace debuggers really like having the vdso properly
On Wed, Aug 26, 2015 at 8:13 PM, Brian Gerst brge...@gmail.com wrote:
On Wed, Aug 26, 2015 at 1:10 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst brge...@gmail.com wrote:
Thing 2: vdso compilation with binutils that doesn't support .cfi
directives
>>> Thing 2: vdso compilation with binutils that doesn't support .cfi directives
>>>
>>> Userspace debuggers really like having the vdso properly
>>> CFI-annotated, and the 32-bit fast syscall entries are annotatied
>>> manually in hexidecimal. AFAIK Jan Beulich is the only person who
>>>
On Tue, Aug 25, 2015 at 9:28 AM, Andy Lutomirski wrote:
>
> I bet that, with a bit of tweaking, that would actually end up faster
> than what we do right now for everything except fully fast-path
> syscalls. This would also be a *huge* sanity improvement for the
> compat case in which the args
On Tue, Aug 25, 2015 at 3:59 AM, Brian Gerst wrote:
> On Mon, Aug 24, 2015 at 5:13 PM, Andy Lutomirski wrote:
>>
>> We could also annotate with syscalls need full regs and jump to the
>> slow path for them. This would leave the fast path unchanged (we
>> could duplicate the sys call table so
On Mon, Aug 24, 2015 at 5:13 PM, Andy Lutomirski wrote:
> Hi all-
>
> I want to (try to) mostly or fully get rid of the messy bits (as
> opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
> There are two major conceptual things that are in the way.
>
> Thing 1: partial pt_regs
>
>
* Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
> > Hi all-
> >
> > I want to (try to) mostly or fully get rid of the messy bits (as
> > opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
> > There are two major conceptual things that are in the way.
> >
> > Thing 1:
* Andy Lutomirski wrote:
> Hi all-
>
> I want to (try to) mostly or fully get rid of the messy bits (as
> opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
> There are two major conceptual things that are in the way.
>
> Thing 1: partial pt_regs
>
> 64-bit fast path syscalls
>>> Andy Lutomirski 08/24/15 11:14 PM >>>
>Thing 1: partial pt_regs
>
>64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and
>r12-r15 are uninitialized. Some syscalls require them to be
>initialized, and they have special awful stubs to do it. The entry
>and exit tracing code
On Tue, Aug 25, 2015 at 3:59 AM, Brian Gerst brge...@gmail.com wrote:
On Mon, Aug 24, 2015 at 5:13 PM, Andy Lutomirski l...@amacapital.net wrote:
We could also annotate with syscalls need full regs and jump to the
slow path for them. This would leave the fast path unchanged (we
could
On Tue, Aug 25, 2015 at 9:28 AM, Andy Lutomirski l...@amacapital.net wrote:
I bet that, with a bit of tweaking, that would actually end up faster
than what we do right now for everything except fully fast-path
syscalls. This would also be a *huge* sanity improvement for the
compat case in
Thing 2: vdso compilation with binutils that doesn't support .cfi directives
Userspace debuggers really like having the vdso properly
CFI-annotated, and the 32-bit fast syscall entries are annotatied
manually in hexidecimal. AFAIK Jan Beulich is the only person who
understands it.
I want
Andy Lutomirski l...@amacapital.net 08/24/15 11:14 PM
Thing 1: partial pt_regs
64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and
r12-r15 are uninitialized. Some syscalls require them to be
initialized, and they have special awful stubs to do it. The entry
and exit tracing
* Andy Lutomirski l...@amacapital.net wrote:
Hi all-
I want to (try to) mostly or fully get rid of the messy bits (as
opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
There are two major conceptual things that are in the way.
Thing 1: partial pt_regs
64-bit fast
* Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@amacapital.net wrote:
Hi all-
I want to (try to) mostly or fully get rid of the messy bits (as
opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
There are two major conceptual things that are in the
On Mon, Aug 24, 2015 at 5:13 PM, Andy Lutomirski l...@amacapital.net wrote:
Hi all-
I want to (try to) mostly or fully get rid of the messy bits (as
opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
There are two major conceptual things that are in the way.
Thing 1: partial
Hi all-
I want to (try to) mostly or fully get rid of the messy bits (as
opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
There are two major conceptual things that are in the way.
Thing 1: partial pt_regs
64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and
Hi all-
I want to (try to) mostly or fully get rid of the messy bits (as
opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
There are two major conceptual things that are in the way.
Thing 1: partial pt_regs
64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and
22 matches
Mail list logo
