On 28.05.2019 20:08, Martin Husemann wrote:
> On Tue, May 28, 2019 at 07:50:34PM +0200, Micha? Górny wrote:
>> Well, if we are only to consider new registers, then we're talking about
>> 16 'pure' ymm registers + 32 zmm registers + 8 kN registers + 1 state
>> register, multiply by two... 114 PT_*
> On May 28, 2019, at 11:16 AM, Michał Górny wrote:
>
>> We already have very strange ones (XMMREGS and VECREGS). Maybe we should just
>> have one ALLREGS thing (identical to the core note) and then discuss how
>> to properly make that sanely versioned and self describing?
>>
>
> That is
On Tue, 2019-05-28 at 20:08 +0200, Martin Husemann wrote:
> On Tue, May 28, 2019 at 07:50:34PM +0200, Micha? Górny wrote:
> > Well, if we are only to consider new registers, then we're talking about
> > 16 'pure' ymm registers + 32 zmm registers + 8 kN registers + 1 state
> > register, multiply by
On Tue, May 28, 2019 at 07:50:34PM +0200, Micha? Górny wrote:
> Well, if we are only to consider new registers, then we're talking about
> 16 'pure' ymm registers + 32 zmm registers + 8 kN registers + 1 state
> register, multiply by two... 114 PT_* requests?
Integers are plenty, but the core file
On Tue, May 28, 2019 at 10:54:45AM -0700, Jason Thorpe wrote:
> The registers are dumped in an ELF note in the same format that
> ptrace gets. We don't currently handle anything other than integer
> registers and basic FP registers in core files at the moment. Look for
> "coredump_note" in
> On May 28, 2019, at 10:48 AM, Martin Husemann wrote:
>> It would make things a bit awkward for core files.
>
> Please excuse my ignorance, but how is ptrace(2) related to core files?
The registers are dumped in an ELF note in the same format that ptrace gets.
We don't currently handle
On Tue, 2019-05-28 at 19:37 +0200, Martin Husemann wrote:
> Stupid question: since this is all very rare and non-performance critical,
> why isn't it done as a single register per call? Adding more registers
> when thy arrive in newer cpu variants, and not worrying about how they
> are saved
On Tue, May 28, 2019 at 10:46:44AM -0700, Jason Thorpe wrote:
>
> > On May 28, 2019, at 10:37 AM, Martin Husemann wrote:
> >
> > Stupid question: since this is all very rare and non-performance critical,
> > why isn't it done as a single register per call? Adding more registers
> > when thy
> On May 28, 2019, at 10:37 AM, Martin Husemann wrote:
>
> Stupid question: since this is all very rare and non-performance critical,
> why isn't it done as a single register per call? Adding more registers
> when thy arrive in newer cpu variants, and not worrying about how they
> are saved
Stupid question: since this is all very rare and non-performance critical,
why isn't it done as a single register per call? Adding more registers
when thy arrive in newer cpu variants, and not worrying about how they
are saved (XSAVE or similar) nor what format is used in the kernel?
So a
On Tue, 2019-05-28 at 19:26 +0200, Kamil Rytarowski wrote:
> On 28.05.2019 18:34, Michał Górny wrote:
> > There is no difference in internal layout or logic between b. and c.
> > In either case, we need to perform XSAVE, process it and copy the data
> > into internal structure. The only
On 28.05.2019 18:34, Michał Górny wrote:
> There is no difference in internal layout or logic between b. and c.
> In either case, we need to perform XSAVE, process it and copy the data
> into internal structure. The only difference is that in b. we handle it
> all in one request, and in c. we do
I'm hoping that whatever solution is arrived at, it does not introduce
any new #ifdef ... #endif variations of structures that might get passed
between kernel and module code. Such variations create dependencies in
the modules which are at best "difficult" to deal with at run-time.
(We
On Tue, 2019-05-28 at 18:08 +0200, Kamil Rytarowski wrote:
> On 28.05.2019 15:20, Michał Górny wrote:
> > Hi,
> >
> > After implementing most of PT_GETXSTATE/PT_SETXSTATE and getting some
> > comments requiring major changes anyway, I'm starting to wonder whether
> > the approach I've followed is
On 28.05.2019 15:20, Michał Górny wrote:
> Hi,
>
> After implementing most of PT_GETXSTATE/PT_SETXSTATE and getting some
> comments requiring major changes anyway, I'm starting to wonder whether
> the approach I've followed is actually the best one. This is especially
> important now that I'm
Hi,
After implementing most of PT_GETXSTATE/PT_SETXSTATE and getting some
comments requiring major changes anyway, I'm starting to wonder whether
the approach I've followed is actually the best one. This is especially
important now that I'm pretty sure that we can't rely on fixed offsets
in
16 matches
Mail list logo
