From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13244 invoked by alias); 8 Aug 2014 07:17:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13218 invoked by uid 89); 8 Aug 2014 07:17:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 08 Aug 2014 07:17:26 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 69CC2340076; Fri, 8 Aug 2014 07:17:24 +0000 (UTC) From: Mike Frysinger To: Eli Zaretskii Cc: brobecker@adacore.com, gdb-patches@sourceware.org, monaka@monami-software.com Subject: Re: [doc] Avoid conflicts between gdb and cross-gdb. Date: Fri, 08 Aug 2014 07:17:00 -0000 Message-ID: <1582806.fEGP7eDcqu@vapier> User-Agent: KMail/4.13.3 (Linux/3.14.2; KDE/4.13.3; x86_64; ; ) In-Reply-To: <83lhqzms89.fsf@gnu.org> References: <6996949.EeennEHWE2@vapier> <83lhqzms89.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1893508.FzATUvWYYB"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00163.txt.bz2 --nextPart1893508.FzATUvWYYB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Content-length: 1900 On Fri 08 Aug 2014 09:05:10 Eli Zaretskii wrote: > > From: Mike Frysinger > > Cc: brobecker@adacore.com, gdb-patches@sourceware.org, > > monaka@monami-software.com Date: Thu, 07 Aug 2014 22:52:57 -0400 > >=20 > > so the first question is, is this scenario important to us ? or do we > > consider people dealing with cross-gdb's to be on their own and to figu= re > > out documentation skew problems themselves ? >=20 > I see no documentation skews here. The GDB manual documents (barring > errors that should be reported and fixed) describes all of its > versions, including cross-gdb. i described the skews in my other e-mail which you responded to. your `inf= o=20 gdb` obviously only describes that specific version of gdb. the further aw= ay=20 your cross version gets (newer or older), the more the manual does not help= =20 but even confuses. you can't even use the online gdb manual because that o= nly=20 reflects the very latest versions (unlike say gcc which archives the manual= =20 for every release online). that leaves people with `man $target-gdb` which= =20 only describes the command line interface. > > lumping it into the category of "if you're > > cross-compiling/debugging, you know what you're doing" doesn't fly > > as there a _lot_ of people who do cross work and know very little > > here -- someone else is responsible for building/packaging the > > toolchain and they were just given it and told "use xxx-gcc and > > xxx-gdb". >=20 > I don't see how people who know very little could ever be able to work > with GDB, or even with a cross-compiler, for that matter. But I guess > we will have to agree to disagree here. then you obviously haven't dealt with real world customers ;). it isn't th= at=20 they can't look up and find information (eventually). but providing a stat= e=20 where they predestined to fail isn't exactly great. -mike= --nextPart1893508.FzATUvWYYB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJT5HmDAAoJEEFjO5/oN/WBw6sP/1pcgMBzr4yWESZ91g7aWP1T GPQmyjiSEz52h4HrOgIXsg1WsxzCXwa3HAVBs389rMBxCoPfci+lKiweZDVnY6S+ RCG7hiZt+EZ1Hr9tsHdm4rL5TCo9OB3/osdc5/STRqSriRCqIDsFjwT/EPGqBCrH Y/RE3CE7b+hXGMyiTbkJD9nV/9VRRrKqyb+euLplGjYH1DDhudcx1FEh3ffJxvIO BuygCKa2hkMnA6Dt4noqFj+Q3k6ieLQnGtChUx6JS7LP4HaKLUgEaEGaf/u7nxe0 yjiXfz4by483kpbrTNOWXeBbOZ14QaKF1hoUm8BBJ7kymHxC/+dNE2TgQnSI/rLg oG8M+UXk7ee5oxAv0N7nRcroN4y96UZQ61FYOS4uB20aHMgUNnmHAP2l/SKn3jWA n1GC5x4mcBBSXtnAc9Td+dJqemoLLNsc829EOw8Jd/f3gHdS+NkbDKSU0OLzfNCR 1MHnExLkLK/W7HcP8kmvUM1k1ZmHS1gv1S22n8/HQ90nhT79k+nR1o2xj4qUTN9z 62XJcQhfqHvWjxMUK5saN4Jk0Vq+ePxXwXUW4IzONPmov6Ijf2ANTc8dH/O8jScl GjeMlim1OvFURA5Ok6YWss7kb9o1CLCRXN0aYM4HjvKeJ1Xz8jixzW7U/s5CGMvd TS04gU3NRjWLYFx6+QJv =qaqb -----END PGP SIGNATURE----- --nextPart1893508.FzATUvWYYB--