Bug 1114588

(In reply to Peter Robinson from comment #0)

> aarch64-linux-nat.c: In function 'aarch64_linux_set_debug_regs':
> aarch64-linux-nat.c:311:29: error: storage size of 'regs' isn't known
>    struct user_hwdebug_state regs;
>                              ^
> aarch64-linux-nat.c: In function 'aarch64_linux_get_debug_reg_capacity':
> aarch64-linux-nat.c:780:29: error: storage size of 'dreg_state' isn't known
>    struct user_hwdebug_state dreg_state;

I don't know why the declaration for the user_hwdebug_state structure
cannot be found in the Fedora build. 

The user_hwdebug_state structure is #define'd in /usr/include/asm/ptrace.h
which is #include'd by aarch64-linux-nat.c on line 34:

      1 /* Native-dependent code for GNU/Linux AArch64.
      2 
      3    Copyright (C) 2011-2013 Free Software Foundation, Inc.
      4    Contributed by ARM Ltd.
      5 
      6    This file is part of GDB.
      7 
      8    This program is free software; you can redistribute it and/or modify
      9    it under the terms of the GNU General Public License as published by
     10    the Free Software Foundation; either version 3 of the License, or
     11    (at your option) any later version.
     12 
     13    This program is distributed in the hope that it will be useful,
     14    but WITHOUT ANY WARRANTY; without even the implied warranty of
     15    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     16    GNU General Public License for more details.
     17 
     18    You should have received a copy of the GNU General Public License
     19    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
     20 
     21 #include "defs.h"
     22 
     23 #include "inferior.h"
     24 #include "gdbcore.h"
     25 #include "regcache.h"
     26 #include "linux-nat.h"
     27 #include "target-descriptions.h"
     28 #include "auxv.h"
     29 #include "gdbcmd.h"
     30 #include "aarch64-tdep.h"
     31 #include "aarch64-linux-tdep.h"
     32 #include "elf/common.h"
     33 
     34 #include <sys/ptrace.h>
     35 #include <sys/utsname.h>
     36 

ptrace.h is part of glibc-headers, as seen on this ARM64 machine:

  # rpm -qf /usr/include/sys/ptrace.h
  glibc-headers-2.17-55.10.sa1.3.aarch64
  #  

I note that in the failing Fedora build, a later version of 
glibc-headers is used compared to the RHEL7 version that is
used to build crash-7.0.7-1.sa1.3.aarch64.rpm:

RHEL7: DEBUG util.py:281:   glibc-headers             aarch64    2.17-55.11.sa1.3           build    632 k

FEDORA: DEBUG util.py:282:   glibc-headers            aarch64   2.19.90-23.fc21               build   635 k

I don't know where to find the aarch64 version of glibc-headers-2.19.90-23.fc21
to see if ptrace.h is still there, or if something's changed with that data 
structure.  Can you give me a pointer to the package repository?

> The user_hwdebug_state structure is #define'd in /usr/include/asm/ptrace.h

I meant declared, not #define'd.  It has to match the kernel version,
which hasn't changed since October 2012:

struct user_hwdebug_state {
        __u32           dbg_info;
        __u32           pad;
        struct {
                __u64   addr;
                __u32   ctrl;
                __u32   pad;
        }               dbg_regs[16];
};

so it seems unlikely/hard-to-explain that it would have changed in
the user-space version.

> ptrace.h is part of glibc-headers, as seen on this ARM64 machine:
> 
>   # rpm -qf /usr/include/sys/ptrace.h
>   glibc-headers-2.17-55.10.sa1.3.aarch64
>   #  
> 
> I note that in the failing Fedora build, a later version of 
> glibc-headers is used compared to the RHEL7 version that is
> used to build crash-7.0.7-1.sa1.3.aarch64.rpm:
> 
> RHEL7: DEBUG util.py:281:   glibc-headers             aarch64   
> 2.17-55.11.sa1.3           build    632 k
> 
> FEDORA: DEBUG util.py:282:   glibc-headers            aarch64  
> 2.19.90-23.fc21               build   635 k
> 
> I don't know where to find the aarch64 version of
> glibc-headers-2.19.90-23.fc21
> to see if ptrace.h is still there, or if something's changed with that data 
> structure.  Can you give me a pointer to the package repository?

It's the standard upstream Fedora rawhide glibc:

http://koji.fedoraproject.org/koji/buildinfo?buildID=539740

Probably the easiest way to get the source is "fedpkg clone glibc; cd glibc; fedpkg prep" and it'll pull it down and apply all the patches. It's basically upstream glibc snapshots, so it'll be pretty close to upstream head for the 2.20 release.

>     33 
>     34 #include <sys/ptrace.h>
>     35 #include <sys/utsname.h>
>     36 
>
> ptrace.h is part of glibc-headers, as seen on this ARM64 machine:
> 
>   # rpm -qf /usr/include/sys/ptrace.h
>   glibc-headers-2.17-55.10.sa1.3.aarch64
>   #  

My mistake -- even though aarch64-linux-nat.c #include's <sys/ptrace.h>,
the structure is declared in <asm/ptrace.h>, which is not directly 
#include'd by the aarch64-linux-nat.c.  So it must be picked up indirectly
by some other #include file. 

Anyway, <asm/ptrace.h> is part of the kernel-headers package.  
In the RHEL7 brew environment where crash builds just fine,
it uses:

  kernel-headers  aarch64  3.15.0-0.rc7.35.sa2  build  875 k

In the failed Fedora build, it uses:

  kernel-headers  aarch64  3.15.0-1.fc21  build  946 k

I downloaded and built the kernel-3.15.0-1.fc21 package, and
as expected, the <asm/ptrace.h> is identical to that contained
in the RHEL7 3.15.0-0.rc7.35.sa2 package.

So at this point I'm trying to figure out how aarch64-linux-nat.c
gets <asm/ptrace.h> included.

FYI still fails with 3.16.0-0.rc3

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2468323

The #include path from aarch64-linux-nat.c to <asm/ptrace.h> goes
like this:

aarch64-linux-nat.c:

  #include "linux-nat.h"

linux-nat.h:

  #include <signal.h>     

/usr/include/signal.h:   (from glibc-headers)

  #if defined __USE_BSD || defined __USE_XOPEN_EXTENDED || defined __USE_XOPEN2K8
  #if defined __USE_XOPEN || defined __USE_XOPEN2K8
      #include <sys/ucontext.h>  

/usr/include/sys/ucontext.h:   (from glibc-headers)

  #include <sys/procfs.h>

/usr/include/sys/procfs.h:    (from glibc-headers)

  #include <asm/ptrace.h>   
 
I tried to build glibc-headers on my ARM64 machine, but it fails.  But
looking at the package contents, I can see the header files above
in the ./sysdeps/unix/sysv/linux/aarch64/sys/<header.h> path.  The
signal.h file has changed its prerequisites for #include'ing 
<sys/ucontext.h> slightly, but I presume they are OK.  But more to
the point, the new <sys/procfs.h> file is certainly the problem, 
because it no longer #include's <asm/ptrace.h>.

The RHEL7 version of <sys/procfs.h> has this section of #include's:

  #include <features.h>
  #include <sys/time.h>
  #include <sys/types.h>
  #include <sys/user.h>
  
  /* We need to see the definition of struct pt_regs but do not want the
     linux PTRACE_* defines since they conflict with the generic eglibc
     definitions in sys/ptrace.h Hence the undef's below.  */
  #include <asm/ptrace.h>
  
  #undef PTRACE_GET_THREAD_AREA
  #undef PTRACE_GETHBPREGS
  #undef PTRACE_SETHBPREGS
  
  #include <sys/user.h>
  
  __BEGIN_DECLS
  

The Fedora version removes the <asm/ptrace.h> #include as well as
the redundant <sys/user.h>:
  
  #include <features.h>
  #include <sys/time.h>
  #include <sys/types.h>
  #include <sys/user.h>
  
  __BEGIN_DECLS


So it looks like the best way around this is to simply drop in
an "#include <asm/ptrace.h>" into the aarch64-linux-nat.c file.

But I have no clue as to how to build/test this package for aarch64.
Is it some kind of one-liner koji command or some such?

> But I have no clue as to how to build/test this package for aarch64.
> Is it some kind of one-liner koji command or some such?

How do you want to handle testing my proposed update(s)?

(In reply to Dave Anderson from comment #7)
> > But I have no clue as to how to build/test this package for aarch64.
> > Is it some kind of one-liner koji command or some such?
> 
> How do you want to handle testing my proposed update(s)?

If you let me know where the patch/tarball is I can do a scratch build for people to test. If you mean for the actual functionality of the changes themselves Brendan can sort that side of things out.

Created attachment 914213 [details]
patch to have aarch64-linux-nat.c #include <asm/ptrace.h> directly



No, it's pretty much just a test to ensure that the build can complete.

The ptrace-related functions that fail to compile could never even get
called.  The embedded gdb code in the crash utility does'nt utilize
the affected ptrace-related code, because it's invoked internally as
"gdb vmlinux" just to be able to get debuginfo data.  

The attached patch would become Patch2 in the crash.spec file.

If you have a src.rpm you can run 

"arm-koji build --scratch rawhide crash-x.y.z-1.src.rpm"

And that will run a scratch build to test the build

(In reply to Peter Robinson from comment #10)
> If you have a src.rpm you can run 
> 
> "arm-koji build --scratch rawhide crash-x.y.z-1.src.rpm"
> 
> And that will run a scratch build to test the build

OK thanks -- I've got a scratch build underway...

  http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2470488

> OK thanks -- I've got a scratch build underway...
>
>  http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2470488

That worked for ARM64.  Now I'm running:
 
  koji build --scratch rawhide crash-7.0.7-2.fc21.src.rpm

to check whether the glibc-headers changes may affect the 
other architectures.

There were no problems with the scratch build on the other architectures.
The fix is checked in and built in rawhide:
 
  Information for build crash-7.0.7-2.fc21
  http://koji.fedoraproject.org/koji/buildinfo?buildID=541670

  Changelog:
  * Wed Jul 02 2014 Dave Anderson <anderson> - 7.0.7-2
  - Fix FTBS for aarch64 (BZ #1114588)

Built on aarch64 rawhide. Thanks