[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "struct user" conflicts on arm



Wookey wrote:

> We can
> 1) Change every app in the world that defines a 'struct user'

> 2) Stop these headers getting brought in when not actually needed
> (it's a relatively recent change that brings it in)
> 3) Change the name in glibc/GDB to something less likely to clash

Some background from a GDB perspective: the files <sys/procfs.h>
and <sys/user.h> define the layout of the various register sets
the kernel provides to user space debuggers via ptrace and/or
core file register note sections.

In the past, it was considered a good idea for this information
to be provided by kernel headers via inclusion into glibc to be
used by GDB sources.  However, this turned out to not be really
feasible with modern GDB: since this information is needed to
access core files, and with a cross-debugger we need to access
core files produced on some other architecture than the host,
we cannot actually rely on system headers (which only provide
information about the host architecture).  Fortunately, the
layout is part of the unchanging kernel ABI, so there is no
real need for GDB to rely on any header files in the first place.
Therefore, GDB is currently in the process to switching to simply
hard-coding register set layouts for various architectures.

Once this process is complete, <sys/user.h> and <sys/procfs.h>
will no longer be needed to build GDB.  (The process is mostly
complete for <sys/user.h>; it will still take a while for
<sys/procfs.h>.)  However, from a system perspective, it is
probably still not a good idea to just remove (or incompatibly
change) those headers: you want to keep the capability to
compile older GDB sources (and possibly other debuggers).


Now, glibc also provides a file <sys/ucontext.h> that defines
layouts of register sets for use with signal handlers as well
as the makecontext/setcontext/getcontext family of routines.

Usually, those layouts tend to be in fact identical to the
layouts described in <sys/user.h> / <sys/procfs.h>.  Apparently,
whoever implemented the ARM version of <sys/ucontext.h> was
trying to avoid some seemingly unnecessary code duplication
by making <sys/ucontext.h> *include* <sys/procfs.h> and using
the information from there directly.  This is not done on other
platforms, for precisely the reason that the <sys/procfs.h>
and <sys/user.h> headers do pollute the name space ...

So I think the right thing to do in the short term would be to
stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the
register set information there directly, even if that means some
duplication of code.  (Again, since this is never-changing ABI,
duplication isn't actually all that bad.  Also, all the other
platforms do it that way too, so why should ARM be different ...)


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


Reply to: