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 real
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 th
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 he
>>> 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
>>> understa
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 ar
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 tha
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: par
* 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 (ex
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
r1
11 matches
Mail list logo
