Re: [PATCH] include/gdb/section-scripts.h: New file.

[Doug Evans <xdje42 at gmail dot com>]

On Thu, Dec 5, 2013 at 11:15 AM, Tom Tromey <tromey@redhat.com> 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 allowed.]
>
> 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 code.
>
> 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 â and their
associated values are reserved, but the languages they represent are
not supported in DWARF
Version 2.

DW_LANG_Cobol74â 0x0005
DW_LANG_Cobol85â 0x0006