Re: "struct user" conflicts on armel and armfh
Carlos O'Donell wrote:
As an upstream glibc maintainer I would be happy to see this fixed in
glibc and gdb, but nobody has stepped up to fix it.
Ok.....
The `struct user` is used by the gdbserver code that uses ptrace
(PTRACE_PEEKUSR/POKEUSR) to peek/poke at the inferior and read out
stored register values from the USER area. The userspace definition of
`struct user` is equivalent to task_regs(child) layout and is an
agreement between the kernel and userspace for debugging.
There appears to be no good reason for it to be called `struct user`
on Linux (on other OSs this is harder to control), it should have been
named something that doesn't clash with the applications namespace
e.g. struct __user.
While renaming the structure would be one soloution to the
conflicts changing a long standing* interface to solve a
problem that is arch specific and has only recently become a
significant issue** seems like a wrong approach to me.
The real problem IMO is that headers that are supposed to be
implementing special purpose interfaces for debugging are
being pulled in by headers that are supposed to be implementing
common public interfaces.
* at least as far back as debian slink
** In squeeze armel signal.h would only include sys/ucontext.h
if explicit defines were set. In wheezy and sid it seems to
include it by default.
Are you volunteering to change glibc and gdb, and work with upstream
to get the changes merged?
Depends on what exactly is involved in doing that and whether we
can agree on how things should be fixed.
As I said i'm not convinced that gdb needs to be changed.
Reply to: