Re: [PATCHSET] saner elf compat

[Al Viro]

On Tue, Dec 22, 2020 at 09:38:35PM +0000, Al Viro wrote:
> On Tue, Dec 22, 2020 at 08:04:31PM +0000, 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
> > Cannot find thread-local storage for LWP 4154, executable file <pathname>
> > Cannot find thread-local variables on this target
> > 
> > buster has libc6-2.28, so that should be fine for the test in question
> > (libthread_db definitely recent enough).  That was n32 gdb; considering
> > how much time it had taken to build that sucker I hadn't tried o32
> > yet.
> > 
> > Note that it's not just with native coredumps - gcore-produced ones give
> > the same result.  That was gdb from binutils-gdb.git; I'm not familiar
> > with gdb guts to start debugging it, so if you have any suggestions
> > in that direction that do not include a full rebuild...  In any case,
> > I won't get around to that until the next week.
> > 
> > Incidentally, build time is bloody awful - 3 days, with qemu-3.1 on
> > 3.5GHz amd64 host, all spent pretty much entirely in userland (both
> > from guest and host POV).  g++-8 is atrociously slow...
> > 
> > That said, I don't see what in that series could possibly mess the
> > things up for tls, while leaving the registers working; the only
> > thing that realistically might've been fucked up is prstatus layout
> > (and possibly size), and that would've screwed the registers as
> > well.
> 
> ... and it smells like the damn thing needs n32 debug info from libthread_db.so
> and/or libpthread.so.  Which is not packaged by debian libc6 mips64el build.
> Sorry, any debugging of that crap is going to happen in January ;-/

Cute...  Completely unrelated, but there's a fun bug in mainline o32
coredumps - say readelf -a core and watch NT_FILE section dump.
Compare that for dumps done on mips32 and mips64 hosts (for the same
o32 binaries, obviously).  Or to gcore(1) results on such processes,
for that matter.

What happens there is that 2aa362c49c31 ("coredump: extend core dump note
section to contain file names of mapped files") that has introduced that
section has added
#define user_long_t            compat_long_t
to fs/compat_binfmt_elf.c, but not to arch/mips/kernel/binfmt_elfo32.c,
resulting in default (long) being used by fill_files_note().