From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-94780-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 28663 invoked by alias); 24 Sep 2012 14:51:40 -0000
Received: (qmail 28652 invoked by uid 22791); 24 Sep 2012 14:51:38 -0000
X-SWARE-Spam-Status: No, hits=-4.3 required=5.0	tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL
X-Spam-Check-By: sourceware.org
Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Sep 2012 14:51:23 +0000
Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MAU00A00ZVF7N00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Mon, 24 Sep 2012 16:51:11 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAU009EIZXAVUB0@a-mtaout23.012.net.il>; Mon, 24 Sep 2012 16:51:10 +0200 (IST)
Date: Mon, 24 Sep 2012 14:51:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH 2/2] Try to initialize data-directory by first searching for "data-directory" in the same directory as the gdb binary
In-reply-to: <CEEFB717-1A10-441A-85BF-4214330D0317@cs.umd.edu>
To: Khoo Yit Phang <khooyp@cs.umd.edu>
Cc: brobecker@adacore.com, jan.kratochvil@redhat.com, gdb-patches@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83y5jziieg.fsf@gnu.org>
References: <21ACC598-F6B4-4117-BA7B-B316414DE9E3@cs.umd.edu> <20120919130040.GA20442@host2.jankratochvil.net> <D25DD5A2-956A-4D0F-9A00-383976EBD397@cs.umd.edu> <20120921183122.GB8747@host2.jankratochvil.net> <E7BD6947-E1B8-4CEC-BBFB-3A8997B64CAE@cs.umd.edu> <20120922110822.GA28159@host2.jankratochvil.net> <78B3333C-92F9-474D-8352-087C5A0F575B@cs.umd.edu> <20120924072945.GA4146@adacore.com> <AF12A41C-7B71-45F6-9496-1C8797774D58@cs.umd.edu> <836273jy7s.fsf@gnu.org> <CEEFB717-1A10-441A-85BF-4214330D0317@cs.umd.edu>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2012-09/txt/msg00503.txt.bz2

> From: Khoo Yit Phang <khooyp@cs.umd.edu>
> Date: Mon, 24 Sep 2012 10:37:17 -0400
> Cc: Khoo Yit Phang <khooyp@cs.umd.edu>,
>  brobecker@adacore.com,
>  jan.kratochvil@redhat.com,
>  gdb-patches@sourceware.org
> 
> > Please don't.  Invoking GDB from the build directory should "just
> > work".
> 
> What do you mean? If we call the shell script "gdb" (only in the build-directory, to clarify; it will not be installed to /usr/bin), then it will "just work" in almost all cases, except when running gdb on gdb.

First, running gdb on gdb is an important use case.

Second, there are systems (like MS-Windows) which cannot run Unix
shell scripts natively.

Third, why should I trust random shell scripts that come with the
distribution?

Forth, having a shell script that shadows a binary leads to confusion
and aggravation if the user is not aware of that dichotomy.

There are probably more reasons why.

> If we patch the gdb binary and incur the risk that a stray data-directory will lead to bugs.

I don't see how is this different from risk of running a stray shell
script.

> Even before my Python patch, it didn't always "just work", since gdb was picking up the wrong data-directory, and any updates to data-directory (XML signals or Python scripts) would have been missed.

I'm okay with fixing that.