Re: "struct user" conflicts on armel and armfh
On Thu, Dec 15, 2011 at 2:15 AM, peter green
<peter.green@postgrad.manchester.ac.uk> wrote:
> 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.
As a first step why don't you try breaking the header include chain in
glibc, and rebuild gdb to ensure everything works?
Applications that actually need `struct user' will need to pull it in
explicitly instead of implicitly through another header.
One thing I wanted to check, but can't (the site is still undergoing
reconstruction after the security breach), is whether or not LSB
documents this interface as pat of the standard.
If it was documented in LSB (which has an ISO standard), you could
argue that the application is non-conforming to LSB, and that the real
fix is to stop using `struct user' because it's part of the standard.
Cheers,
Carlos.
Reply to: