Re: [PATCH] crash-gcore-command extension module: ARM64 support

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

 



> -----Original Message-----
> From: crash-utility-bounces@xxxxxxxxxx [mailto:crash-utility-
> bounces@xxxxxxxxxx] On Behalf Of Dave Anderson
> Sent: Wednesday, July 30, 2014 8:55 PM
> To: Discussion list for crash utility usage, maintenance and development
> Subject: Re:  [PATCH] crash-gcore-command extension module:
> ARM64 support
> 
> 
> 
> ----- Original Message -----
> > Hi Dave,
> >
> > which glibc version are you using? for us, it seems
> > /usr/include/sys/procfs.h is not included, we still met build error
> > with your patch
> 
> The ARM64 machine I'm building on is based upon glibc-headers-2.17-55.11, But
> /usr/include/sys/procfs.h has been part of glibc-headers since at least
> glibc-headers-2.3.2-95.  So if I understand you correctly, does the
> /usr/include/sys/uncontext.h *not* include <sys/procfs.h> on your system?
> 
yes, actually I am building crash/gcore on a x86_64 machine, not an ARM64 machine

> >
> > so Lei and me made some patches to use the old way for ARM64, and also
> > add compat mode support for ARM64
> 
> That certainly makes the patch much uglier.  Would it be possible to
> explicitly #include <sys/procfs.h> encapsulated by #ifdef ARM64 in the
> relevant places?
> 
> >
> > these patches are verified on both ARM64 compat mode and ARM64, please
> > help review, thanks
> 
> Look, we're getting ahead of things.  Let's defer to Daisuke to decide how he
> is going to approach this first.

this is OK

Best Regards,
Wei

> 
> Dave
> 
> 
> 
> > Best Regards,
> > Wei
> >
> > -----Original Message-----
> > From: crash-utility-bounces@xxxxxxxxxx
> > [mailto:crash-utility-bounces@xxxxxxxxxx] On Behalf Of Dave Anderson
> > Sent: Tuesday, July 29, 2014 8:31 PM
> > To: HATAYAMA Daisuke
> > Cc: crash-utility@xxxxxxxxxx
> > Subject: Re:  [PATCH] crash-gcore-command extension module:
> > ARM64 support
> >
> >
> >
> > ----- Original Message -----
> > > From: Dave Anderson <anderson@xxxxxxxxxx>
> > > Subject: [PATCH] crash-gcore-command extension module: ARM64 support
> > > Date: Thu, 17 Jul 2014 12:04:45 -0400
> > >
> > > >
> > > >
> > > > Hello Daisuke,
> > > >
> > >
> > > Hello Dave,
> > >
> > > Sorry for very late responce....
> > >
> > > > Attached is a patch to introduce support for the ARM64
> > > > architecture for the gcore extension module.
> > > >
> > > > The patch is fairly straight-forward other than the fact that on
> > > > ARM64 machines, the chain of headers included from the crash
> > > > utility's "defs.h" looks like this:
> > > >
> > > >   /usr/include/crash/defs.h
> > > >     /usr/include/signal.h
> > > >       /usr/include/sys/ucontext.h
> > > >         /usr/include/sys/procfs.h
> > > >
> > > > The <sys/procfs.h> file defines several of the ELF-related
> > > > structures that are hard-coded in gcore_defs.h, causing compile
> > > > failures due to duplicate structure declarations.
> > > >
> > > > Note that the <sys/ucontext.h> file on the other three
> > > > architectures does not #include <sys/procfs.h> so there are no
> > > > conflicts.  It would be possible to move all architectures to
> > > > include <sys/procfs.h>, but for example, that would also bring in
> > > > the <sys/user.h> definition of the user_regs_struct, which in turn
> > > > causes a myriad of register name mismatches in gcore_x86.c.
> > > > So for the sake of simplicity, wherever there is an ARM64-only
> > > > duplicate structure or definition in gcore_defs.h, I've
> > > > encapsulated them
> > > > by:
> > > >
> > > >   #if defined(X86) || defined(X86_64) || defined(ARM)
> > > >
> > >
> > > Thanks for this explanation. I'll also try to investigate this.
> > >
> > > > Also, there are two generic fixes, one where the gcore module
> > > > fails on Linux 3.11 and later kernels due to a structure member
> > > > name change, and another that changes the getopt() return variable
> > > > to an "int" instead of a "char".
> > > >
> > > > Here are the details:
> > > >
> > > >   gcore.mk:
> > > >
> > > >     - Introduce ARM64 as a supported architecture
> > > >     - Add libgcore/gcore_arm64 to GCORE_CFILES
> > > >
> > > >   gcore.c:
> > > >
> > > >     - In cmd_gcore() change "c" type to "int" to correctly match
> > > >       the return type of getopt(); without it, the while loop
> > > >       spins indefinitely on ARM64.
> > >
> > > >     - In gcore_offset_table_init(), account for the Linux 3.11
> > > >       structure member name-change from ns_proxy.pid_ns to
> > > >       ns_proxy.pid_ns_for_children; without it, the gcore command
> > > >       fails during initialization.
> > >
> > > I've already dealt with this locally, but thanks.
> > >
> > > >
> > > >   libgcore/gcore_defs.h:
> > > >
> > > >     - Add ARM64 ELF- and REGSET_VIEW-related #defines required for
> > > >       each architecture.
> > > >     - Account for variable page sizes in ARM64.
> > > >     - Restrict the hard-coded ELF_NGREG, elf_siginfo, elf_prstatus,
> > > >       __kernel_old_uid_t and __kernel_old_gid_t, and elf_prsinfo
> > > >       definitions to X86, X86_64 and ARM architectures.
> > > >     - Add ARM64 thread_struct_fpsmid_state and thread_struct_tp_value
> > > >       offsets to gcore_offset_table.
> > > >
> > > >   libgcore/gcore_coredump.c:
> > > >
> > > >     - In fill_prstatus_note(), account for the ARM64 usage of
> > > >       "user_pt_regs" structure instead of the "user_regs_struct"
> > > >       used by the other architectures.
> > > >
> > > >   libgcore/gcore_arm64.c:
> > > >
> > > >     - Implement ARM64-specific user_regset and user_regset_view
> > > >       structures and all required support functions.
> > > >
> > > > Please accept these changes into an new package version.
> > > >
> > >
> > > I'll commit these into my local repository with some changes for
> > > ease of my maintainance purpose. Maybe, I'll ask you to review the
> > > changed version.
> >
> > Excellent -- thanks!  I thought I'd lost you!
> >
> > Dave
> >
> > --
> > Crash-utility mailing list
> > Crash-utility@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> > --
> > Crash-utility mailing list
> > Crash-utility@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/crash-utility
> 
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux