From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47176 invoked by alias); 27 Sep 2018 08:43:52 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 47134 invoked by uid 89); 27 Sep 2018 08:43:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=typedefs X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 08:43:49 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F0791307D84A; Thu, 27 Sep 2018 08:43:47 +0000 (UTC) Received: from blade.nx (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id B794360FC3; Thu, 27 Sep 2018 08:43:47 +0000 (UTC) Received: by blade.nx (Postfix, from userid 1000) id AD82280B0905; Thu, 27 Sep 2018 09:43:46 +0100 (BST) Date: Thu, 27 Sep 2018 08:43:00 -0000 From: Gary Benson To: Simon Marchi Cc: gdb@sourceware.org Subject: Re: Minimum kernel and glibc versions to build on GNU/Linux? Message-ID: <20180927084345.GA25872@blade.nx> References: <320801121f7fa389eaa3e149de74d230@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <320801121f7fa389eaa3e149de74d230@polymtl.ca> X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00030.txt.bz2 Simon Marchi wrote: > On 2018-09-26 10:53, Gary Benson wrote: > > Are there specific minimum kernel and glibc versions required to > > build GDB or gdbserver on GNU/Linux? I'm working on a refactor > > that's complicated by workarounds for ancient versions of both > > (circa 2002) and I'm wondering if I can just drop the workarounds. > > I'd say that if something was introduced in 2002, we can safely > assume it will be available. But it would be easier to tell if you > specified which particular feature you would like to rely on. Hi Simon, I noticed there's two gdb_proc_service.h files, so I'm trying to merge them. I have them pretty close, but I'm still working on this difference: #ifndef HAVE_PRGREGSET_T -typedef gdb_gregset_t prgregset_t; +typedef elf_gregset_t prgregset_t; #endif #ifndef HAVE_PRFPREGSET_T -typedef gdb_fpregset_t prfpregset_t; +typedef elf_fpregset_t prfpregset_t; #endif Now, my machine has: /usr/include/linux/elfcore.h: typedef elf_gregset_t gregset_t; /usr/include/linux/elfcore.h: typedef elf_fpregset_t fpregset_t; and: gdb/gregset.h: #define GDB_GREGSET_T gregset_t gdb/gregset.h:#define GDB_FPREGSET_T fpregset_t gdb/gregset.h: typedef GDB_GREGSET_T gdb_gregset_t; gdb/gregset.h:typedef GDB_FPREGSET_T gdb_fpregset_t; so they are actually the same types on my machine. I'm not sure how long this equivalence has been true, or if it's true on all platforms, but if it is I'll make them both use the same type. Except, the workarounds complicate things. GDB has this: /* Unfortunately glibc 2.1.3 was released with a broken prfpregset_t type. We let configure check for this lossage, and make appropriate typedefs here. */ #ifdef PRFPREGSET_T_BROKEN typedef gdb_fpregset_t gdb_prfpregset_t; #else typedef prfpregset_t gdb_prfpregset_t; #endif and gdbserver has this: /* Not all platforms bring in via . If wasn't enough to find elf_fpregset_t, try the kernel headers also (but don't if we don't need to). */ #ifndef HAVE_ELF_FPREGSET_T # ifdef HAVE_LINUX_ELF_H # include # endif #endif I think nobody needs the GDB workaround. glibc 2.1.3 was released 2000-02-24 and superseded 2000-11-09 so this is real old, and the workaround isn't in gdbserver, so presumably gdbserver would be failing to build if anyone still required that workaround, unless they're building GDB without gdbserver (is this possible?) I'm not sure if the gdbserver-only workaround is required, maybe it is on some non x86 platforms, but if it's valid to make gdbserver use gregset_t and fpregset_t everywhere then the gdbserver workaround shouldn't be needed. Anyway, I'm still researching this. Note that the gdb_proc_service.h files are only used on GNU/Linux, the Solaris implementation is entirely separate, so I don't need to consider that. Cheers, Gary