On Wed, Dec 23, 2020 at 07:03:20AM +, Al Viro wrote:
Argh Wrong commit blamed - the parent of the correct one.
It's actually 2aa362c49c31 ("coredump: extend core dump note section to
contain file names of mapped files"). My apologies - fat-fingered
cut'n'paste...
[Denys Vlasenko cc'd]
On Wed, Dec 16, 2020 at 09:44:53AM +, Maciej W. Rozycki wrote:
> On Wed, 16 Dec 2020, Al Viro wrote:
>
> > > It may be worth pushing through GDB's gdb.threads/tls-core.exp test
> > > case,
> > > making sure no UNSUPPORTED results have been produced due to resource
>
On Tue, Dec 22, 2020 at 09:38:35PM +, Al Viro wrote:
> On Tue, Dec 22, 2020 at 08:04:31PM +, Al Viro wrote:
>
> > FWIW, on debian/mips64el (both stretch and buster) the test fails with the
> > distro kernels (4.9- and 4.19-based) as well as with 5.10-rc1 and
> > 5.10-rc1+that series, all
On Tue, Dec 22, 2020 at 08:04:31PM +, Al Viro wrote:
> FWIW, on debian/mips64el (both stretch and buster) the test fails with the
> distro kernels (4.9- and 4.19-based) as well as with 5.10-rc1 and
> 5.10-rc1+that series, all in the same way:
> [Current thread is 1 (LWP 4154)]
> (gdb) p/x foo
On Wed, Dec 16, 2020 at 09:44:53AM +, Maciej W. Rozycki wrote:
> On Wed, 16 Dec 2020, Al Viro wrote:
>
> > > It may be worth pushing through GDB's gdb.threads/tls-core.exp test
> > > case,
> > > making sure no UNSUPPORTED results have been produced due to resource
> > > limits preventing
On Wed, 16 Dec 2020, Al Viro wrote:
> > It may be worth pushing through GDB's gdb.threads/tls-core.exp test case,
> > making sure no UNSUPPORTED results have been produced due to resource
> > limits preventing a core from being dumped (and no FAILs, of course), with
> > o32/n32 native GDB.
On Mon, Dec 07, 2020 at 06:01:43PM +, Maciej W. Rozycki wrote:
> On Thu, 3 Dec 2020, Al Viro wrote:
>
> > > Linux-mips was cc'd, but I'm adding Thomas B to the cc here explicitly
> > > just so that he has a heads-up on this thing and can go and look at
> > > the mailing list in case it goes
On Thu, Dec 03, 2020 at 11:03:36PM +, Al Viro wrote:
> On Thu, Dec 03, 2020 at 02:09:04PM -0800, Linus Torvalds wrote:
> > On Thu, Dec 3, 2020 at 1:46 PM Al Viro wrote:
> > >
> > > The answer (for mainline) is that mips compat does *NOT* want
> > > COMPAT_BINFMT_ELF. Not a problem with that
On Thu, 3 Dec 2020, Al Viro wrote:
> > Linux-mips was cc'd, but I'm adding Thomas B to the cc here explicitly
> > just so that he has a heads-up on this thing and can go and look at
> > the mailing list in case it goes to a separate mailbox for him..
>
> I would certainly appreciate review and
On December 5, 2020 7:23:05 PM PST, Al Viro wrote:
>On Thu, Dec 03, 2020 at 11:03:36PM +, Al Viro wrote:
>> > > The answer (for mainline) is that mips compat does *NOT* want
>> > > COMPAT_BINFMT_ELF. Not a problem with that series, though, so
>I'd
>> > > retested it (seems to work, both for
On Thu, Dec 03, 2020 at 11:03:36PM +, Al Viro wrote:
> > > The answer (for mainline) is that mips compat does *NOT* want
> > > COMPAT_BINFMT_ELF. Not a problem with that series, though, so I'd
> > > retested it (seems to work, both for x86_64 and mips64, execs and
> > > coredumps for all
On Thu, Dec 03, 2020 at 02:09:04PM -0800, Linus Torvalds wrote:
> On Thu, Dec 3, 2020 at 1:46 PM Al Viro wrote:
> >
> > The answer (for mainline) is that mips compat does *NOT* want
> > COMPAT_BINFMT_ELF. Not a problem with that series, though, so I'd
> > retested it (seems to work, both for
On Thu, Dec 3, 2020 at 1:46 PM Al Viro wrote:
>
> The answer (for mainline) is that mips compat does *NOT* want
> COMPAT_BINFMT_ELF. Not a problem with that series, though, so I'd
> retested it (seems to work, both for x86_64 and mips64, execs and
> coredumps for all ABIs alike), with
This series deals with the warts in ELF compat on triarch
architectures (x86_64 and mips64, that is).
x86_64 at least does use compat_binfmt_elf.c for both
32bit ABIs; the way it is done is ugly as hell, though, and more
than slightly brittle (see asm/compat.h for PRSTATUS_SIZE
14 matches
Mail list logo
