From: John Baldwin <jhb@freebsd.org>
To: gdb-patches@sourceware.org
Cc: Rainer Orth <ro@cebitec.uni-bielefeld.de>
Subject: Re: Remove ioctl-based procfs support on Solaris
Date: Tue, 26 Sep 2017 21:09:00 -0000 [thread overview]
Message-ID: <5190367.sVyILAhGg6@ralph.baldwin.cx> (raw)
In-Reply-To: <yddy3p1vebc.fsf@CeBiTec.Uni-Bielefeld.DE>
On Tuesday, September 26, 2017 02:23:35 PM Rainer Orth wrote:
> This is the previously mentioned patch to get rid of
> unstructured/ioctl-based procfs support in procfs.c. Given that support
> for structured procfs was introduced in Solaris 2.6 back in 1997 and
> we're just removing support for Solaris < 10, there's no point in
> carrying that baggage (and tons of support for IRIX and OSF/11 as well)
> around any longer.
>
> Most of the patch should be straightforward (removing support for
> !NEW_PROC_API, non-Solaris OSes and pre-Solaris 10 quirks).
>
> Only a few points need explanations:
>
> * <sys/syscall.h> was already included unconditionally in most places,
> so there's no need to have guards in a few remaining ones.
>
> * configure.host already obsoletes i?86-*-sysv4.2, i?86-*-sysv5, so
> NEW_PROC_API detection for those in configure.ac can go.
>
> * I'm still including <sys/procfs.h> with #define _STRUCTURED_PROC 1.
> Theoretically, it would be better to include <procfs.h> on Solaris
> (which includes that define), but that breaks the build over
> <procfs.h> vs. gdb's "procfs.h", and doesn't exist on Linux.
>
> * I've regenerated syscall_table[] in proc-events.c with a small script
> from Solaris 10, 11.3, 11.4 <sys/syscall.h>, so there should be no
> traces of older Solaris versions and other OSes left.
>
> * prsysent_t and DYNAMIC_SYSCALLS was only used for AIX 5, but AIX
> doesn't use procfs.c any longer, so all related code can go.
>
> The patch was generated with diff -w so one can easier see changes
> without being distracted by simple reindentations.
>
> So far, it has only been compiled and smoke-tested on
> amd64-pc-solaris2.1[01], sparcv9-sun-solaris2.1[01], and
> x86_64-pc-linux-gnu. Certainly needs more testing (Solaris 11.3
> vs. 11.4, 32-bit gdb, testsuite once I've figured out what's wrong on
> Solaris 10 etc.), but it's enough to get a first impression how much
> cleanup is possible here.
FYI, bsd-kvm.c uses HAVE_SYS_USER_H and also uses _KMEMUSER (which your
ChangeLog mentions, but I didn't see it removed in the configure.ac diff)
bsd-kvm.c also uses <sys/proc.h> but it uses it unconditionally.
--
John Baldwin
next prev parent reply other threads:[~2017-09-26 21:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-26 12:25 Rainer Orth
2017-09-26 14:03 ` Pedro Alves
2017-09-27 8:44 ` Rainer Orth
2017-09-27 11:07 ` Pedro Alves
2017-11-30 13:42 ` Rainer Orth
2017-11-30 14:51 ` Pedro Alves
2017-09-26 21:09 ` John Baldwin [this message]
2017-09-27 8:48 ` Rainer Orth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5190367.sVyILAhGg6@ralph.baldwin.cx \
--to=jhb@freebsd.org \
--cc=gdb-patches@sourceware.org \
--cc=ro@cebitec.uni-bielefeld.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox