From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21534 invoked by alias); 15 Oct 2015 11:38:40 -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 18934 invoked by uid 89); 15 Oct 2015 11:38:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 15 Oct 2015 11:38:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id F27EDC0BFD2E for ; Thu, 15 Oct 2015 11:38:37 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9FBcaEP016331 for ; Thu, 15 Oct 2015 07:38:37 -0400 Message-ID: <561F903C.2090203@redhat.com> Date: Thu, 15 Oct 2015 11:38:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "gdb@sourceware.org" Subject: Oldest supported Linux kernel version (require PTRACE_EVENT_CLONE?) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-10/txt/msg00078.txt.bz2 Hi, GDB currently has no guideline on the oldest version of the Linux kernel gdb supports. For every new feature the kernel introduces, we keep old fallback code, and as time (years) goes by, we keep the old code working, and tend to leave it in place. As a result we're probably carrying around old code that works around bugs and missing features in ancient kernels that nobody expects new gdb to ever run on. Such fallback code obviously increases maintenance burden, often confuses newcomers, and sometimes influences design decisions deep in the ptrace backends and sometimes in the remote protocol. For example, on systems that don't support PTRACE_EVENT_CLONE, both gdb and gdbserver coordinate with libthread_db.so to insert breakpoints at magic locations in libpthread.so, in order to thread creation and thread death. The ongoing work to make gdbserver support software single-stepping itself, necessary for tracepoints on ARM, MIPS and other architectures where the CPU doesn't offer a hardware single-step facility, trips on these magic breakpoints -- the question of how to fit the new software single-step mechanism with those breakpoints naturally comes up. However, PTRACE_EVENT_CLONE was first introduced in Linux 2.5.46, released in November 2002. So I think it's reasonable to just remove support for kernels that don't support PTRACE_EVENT_CLONE, and sidestep the libthread_db breakpoints issues entirely. Comments? Thanks, Pedro Alves