From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 20:44:43 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D745CF8 for ; Thu, 10 Apr 2014 20:44:43 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E473D12B4 for ; Thu, 10 Apr 2014 20:44:42 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id um1so4430954pbc.16 for ; Thu, 10 Apr 2014 13:44:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tyaIXj8qS/qU9qBjMcjhzgUJ00J4qVvyMGIRxQu5v0s=; b=jdUhdkEb2UqDCEpvRPMaRQgUl8OmQVnnNL5AIOh+5oThWLUp3bTIgLE7AyIZ7ZBvkb Ori/sEsrqPYHRtphdZ9i5/t0Ynn5sj5LX9MceImxLGZcN7A5RB2nSGXM+/0LStrnEI/8 Ve0H/+S7RGPax+zbtigZ3m/If7FQm8x3G8RovWBj+2JX7htFyJZLiUCyByV2FISOP2xt VB8dGLxFHBqTVnxjmLt0Gutl3qI8mI/In+nBUlUacIhoWUMuhw5OhkTcMomnJLMHqNBV 3dyUDCYZPD8Hfg9hgmwSIo24LYTIB5KiAA3spX+tJbrIvsorYgPUvQ11MThY+iU+8BOK J9Ug== X-Gm-Message-State: ALoCoQmVO7fDRQNWeGYYWoZUyH8ZREF8tsFJute4IwGxAPtapaUM2cq3igHbkpcYKifaJB4Z1s1m X-Received: by 10.66.221.99 with SMTP id qd3mr22499987pac.46.1397162240844; Thu, 10 Apr 2014 13:37:20 -0700 (PDT) Received: from [10.64.24.116] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id v1sm11059894pbl.1.2014.04.10.13.37.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 13:37:20 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Time for turning off gdb by default? Or worse... From: Warner Losh In-Reply-To: <201404091145.58792.jhb@freebsd.org> Date: Thu, 10 Apr 2014 14:37:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <674B7C0B-9235-4030-9A44-7F9984CA2F67@bsdimp.com> References: <201404091145.58792.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:44:43 -0000 OK. Here=92s the summary of the thread: (1) gdb in tree is ancient (2) kgdb is quite useful, and only in tree (3) ports gdb rocks, but=85 (4) ports gdb exists only for a few architectures (5) Fixing ptrace will allow us to use a more-stock gdb Action items: (1) Create a wiki page with timeline to deactivation and removal. (2) Create milestones along the path for (a) kgdb + devel/gdb* (b) architectural coverage (c) ptrace fixes (3) profit. I=92ve done these steps and documented them at = https://wiki.freebsd.org/GdbRetirement to allow work to progress (or = not) without repeating this discussion. Thanks for everybody=92s = feedback. Feel free to comment on the wiki page or edit it for missing = items (or testing you=92ve done). At this point, I=92m withdrawing the gdb disabled by default patches. Warner On Apr 9, 2014, at 9:45 AM, John Baldwin wrote: > On Tuesday, April 08, 2014 4:34:35 pm Warner Losh wrote: >> Greetings, >>=20 >> The gdb in the tree seems to be of very limited usefulness these = days. It >> doesn=92t seem to work on clang-enabled architectures w/o building = -gdwarf-2, >> it doesn=92t seem to work with threaded applications, and on some >> architectures it doesn=92t seem to work at all (mips comes to mind, = but it may >> have been the two binaries I tried). >>=20 >> It seems like we=92d be doing our users a favor by applying: >>=20 >> diff -r 8bfca9de870e share/mk/bsd.own.mk >> --- a/share/mk/bsd.own.mk >> +++ b/share/mk/bsd.own.mk >> @@ -266,7 +266,6 @@ WITH_HESIOD=3D >> FREEBSD_UPDATE \ >> GAMES \ >> GCOV \ >> - GDB \ >> GNU \ >> GNU_GREP_COMPAT \ >> GPIB \ >> @@ -355,6 +354,7 @@ WITH_HESIOD=3D >> CLANG_EXTRAS \ >> CTF \ >> DEBUG_FILES \ >> + GDB \ >> HESIOD \ >> INSTALL_AS_USER \ >> LLDB \ >>=20 >> to the tree, which will turn gdb off by default. It may make more = sense to >> just remove it entirely, but I=92m not sure I want to go there just = yet in >> case there are things that I=92m missing. I believe that the port = will be >> adequate for all architectures we support, but haven=92t tested this = directly >> yet. I do know that on amd64, the port just worked, where the in-tree = gdb >> was an epic fail. >=20 > kgdb is a must. I think it would be less work to forward port kgdb = support > into gdb7 from ports than to keep our ancient gdb alive. Some things = I can > think of for gdb7: >=20 > 1) The threads patch could be greatly simplified if we fixed the = ptrace > backend to properly handle inferiors with tids. This would remove = a > lot of the threads patch where the thread inferior tries to invoke > ptrace directly and convert registers, etc. The way it does this = now > is a total hack and requires much larger patches. This would also > make it a lot easier to get thread debugging working on more > architectures as the thread-db bits would become mostly MI (if not > entirely) >=20 > 2) Porting the kgdb frontend to work with gdb7. It would be nicer to > have a more modern base for kgdb and the ability to use python > scripting with kgdb, custom printers for in-kernel structures, etc. >=20 > I think if we have a useful devel/kgdb that builds against devel/gdb = we > can probably think about retiring gdb, but it's premature = right > now. >=20 > --=20 > John Baldwin