From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14156 invoked by alias); 7 Dec 2013 20:56:26 -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 14139 invoked by uid 89); 7 Dec 2013 20:56:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-we0-f182.google.com Received: from Unknown (HELO mail-we0-f182.google.com) (74.125.82.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 07 Dec 2013 20:56:25 +0000 Received: by mail-we0-f182.google.com with SMTP id q59so1987275wes.41 for ; Sat, 07 Dec 2013 12:56:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.232.133 with SMTP id to5mr27165148wjc.41.1386449775418; Sat, 07 Dec 2013 12:56:15 -0800 (PST) Received: by 10.194.37.73 with HTTP; Sat, 7 Dec 2013 12:56:15 -0800 (PST) In-Reply-To: <87bo0vnm6x.fsf@fleche.redhat.com> References: <87eh5vwaa3.fsf@fleche.redhat.com> <87bo0vnm6x.fsf@fleche.redhat.com> Date: Sat, 07 Dec 2013 20:56:00 -0000 Message-ID: Subject: Re: [PATCH] include/gdb/section-scripts.h: New file. From: Doug Evans To: Tom Tromey Cc: "gdb-patches@sourceware.org" , binutils@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00281.txt.bz2 On Thu, Dec 5, 2013 at 11:15 AM, Tom Tromey wrote: > Tom> I don't see why this needs to go in include. > > Doug> So you would have code that puts contents in this section using > Doug> magic numbers? Eh? This doesn't make any sense. > > I didn't say that. Then you're ok with having a header that defines these magic numbers? > Doug> Why does dwarf2.def exist (for example) ? > > Because it has multiple in-tree users that ought to be kept in sync, > including some in gcc. The point is it's s.o.p. to put a table of magic numbers in a header. Heck, we even put #define's in headers that are used just for documentation purposes (at least they're not used by any code, and it's unlikely at least some of what I've found was ever intended to be used with code, per se, they'rethere "just in case" and for doc purposes AFAICT). binutils-gdb has plenty of them. Plus it's not just in tree users. Another thing I'd *like* to do is install this header with "make install". > Doug> [The dwarf format is far more complicated, obvously. But I didn't > Doug> know there was > Doug> a threshold of magic numbers was required before a header was allow= ed.] > > I don't think there is, and I didn't say that either. > > Doug> +/* Native GDB scripts are not currently supported in > Doug> .debug_gdb_scripts, > Doug> + but we reserve a value for it. */ > Doug> +/*#define SECTION_SCRIPT_ID_GDB_FILE 2*/ > > Tom> There's no need either to reserve a value or to add commented out co= de. > > Doug> I'm curious how I would apply this rule in general. > > 1. Don't check in commented-out code. If this were code that would be one thing, but this is an entry in a table of magic numbers. It's not uncommon to reserve a value. If the gnu tools now have a rule that this is now prohibited, we'd better write it down. It's hard to imagine someone not wanting to reserve a value in another context in the future, and I think it'll simplify the subsequent discussion if one can just refer to a community approved rule. > 2. If a format is versioned or otherwise extensible, there is never a > need to reserve space for a future change. Instead just use the > versioning or extension mechanism when the relevant change is made. > In this case the appropriate time would be when actually changing gdb > to read gdb scripts from the section. I think you meant to qualify "never". dwarf is extensible. For example, one may want to ensure ahead of time that when the time comes one doesn't have to extend the format for the value in question. One may also wish to reserve values so that when the time comes to needing to extend the format, how that extension will work has already been thought out. I looked in the dwarf2 spec (I realize we're now at v4). It reserved two DW_LANG values for cobol. Heh. 7.12 Source Languages The encodings for source languages are given in Figure 28. Names marked with =E2=80=A0 and their associated values are reserved, but the languages they represent are not supported in DWARF Version 2. DW_LANG_Cobol74=E2=80=A0 0x0005 DW_LANG_Cobol85=E2=80=A0 0x0006