gdb: Remove LANG_MAGIC

  The language_defn structure has an la_magic field, this used to be
used as a basic check that the language_defn structure had the
expected layout - at least the end of the structure was where we
expected it to be.

This feature only really makes sense if we imagine GDB dynamically
loading language support from dynamic libraries, where a version
mismatch might cause problems.

However, in current GDB language support is statically built into GDB,
and since this commit:

    commit 47e77640be31fc1a4eb3718f594ed5fd0faff065
    Date:   Thu Jul 20 18:28:01 2017 +0100

        Make language_def O(1)

the existing (if pointless) check of the la_magic field was removed.

There now appears to be no use of the la_magic field, and I propose
that we delete it.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (ada_language_defn): Remove use of LANG_MAGIC.
	* c-lang.c (c_language_defn): Likewise.
	(cplus_language_defn): Likewise.
	(asm_language_defn): Likewise.
	(minimal_language_defn): Likewise.
	* d-lang.c (d_language_defn): Likewise.
	* f-lang.c (f_language_defn): Likewise.
	* go-lang.c (go_language_defn): Likewise.
	* language.c (unknown_language_defn): Likewise.
	(auto_language_defn): Likewise.
	* language.h (struct language_defn): Remove la_magic field.
	(LANG_MAGIC): Delete.
	* m2-lang.c (m2_language_defn): Remove use of LANG_MAGIC.
	* objc-lang.c (objc_language_defn): Likewise.
	* opencl-lang.c (opencl_language_defn): Likewise.
	* p-lang.c (pascal_language_defn): Likewise.
	* rust-lang.c (rust_language_defn): Likewise.
---
 gdb/ChangeLog     | 20 ++++++++++++++++++++
 gdb/ada-lang.c    |  3 +--
 gdb/c-lang.c      | 12 ++++--------
 gdb/d-lang.c      |  3 +--
 gdb/f-lang.c      |  3 +--
 gdb/go-lang.c     |  3 +--
 gdb/language.c    |  6 ++----
 gdb/language.h    |  8 --------
 gdb/m2-lang.c     |  3 +--
 gdb/objc-lang.c   |  3 +--
 gdb/opencl-lang.c |  3 +--
 gdb/p-lang.c      |  3 +--
 gdb/rust-lang.c   |  3 +--
 13 files changed, 35 insertions(+), 38 deletions(-)
  

On 2019-04-11 7:23 p.m., Andrew Burgess wrote:
> The language_defn structure has an la_magic field, this used to be
> used as a basic check that the language_defn structure had the
> expected layout - at least the end of the structure was where we
> expected it to be.
> 
> This feature only really makes sense if we imagine GDB dynamically
> loading language support from dynamic libraries, where a version
> mismatch might cause problems.
> 
> However, in current GDB language support is statically built into GDB,
> and since this commit:
> 
>     commit 47e77640be31fc1a4eb3718f594ed5fd0faff065
>     Date:   Thu Jul 20 18:28:01 2017 +0100
> 
>         Make language_def O(1)
> 
> the existing (if pointless) check of the la_magic field was removed.
> 
> There now appears to be no use of the la_magic field, and I propose
> that we delete it.
> 
> There should be no user visible changes after this commit.

Given that nothing even checks it, this LGTM.

Simon
  

On 4/12/19 12:23 AM, Andrew Burgess wrote:
> The language_defn structure has an la_magic field, this used to be
> used as a basic check that the language_defn structure had the
> expected layout - at least the end of the structure was where we
> expected it to be.
> 
> This feature only really makes sense if we imagine GDB dynamically
> loading language support from dynamic libraries, where a version
> mismatch might cause problems.

We used to have more magic fields like these in other structures,
like target_ops, for example.  IIRC, their intended purpose was to
catch miscompilation, before we had Makefile auto-dependencies.  Before
that, it was common to change the structure's definition, rebuild, and
then find out that gdb hit a "failed internal consistency check" assertion,
because some of the .o files hadn't been rebuilt to reflect the new layout.

For example, the target_ops magic said:

 /* Magic number for checking ops size.  If a struct doesn't end with this
    number, somebody changed the declaration but didn't change all the
    places that initialize one.  */

 #define        OPS_MAGIC       3840

With auto-dependencies, the problem this "solved" is largely a
thing of the past.

Thanks,
Pedro Alves
  

* Pedro Alves <palves@redhat.com> [2019-04-12 10:50:00 +0100]:

> On 4/12/19 12:23 AM, Andrew Burgess wrote:
> > The language_defn structure has an la_magic field, this used to be
> > used as a basic check that the language_defn structure had the
> > expected layout - at least the end of the structure was where we
> > expected it to be.
> > 
> > This feature only really makes sense if we imagine GDB dynamically
> > loading language support from dynamic libraries, where a version
> > mismatch might cause problems.
> 
> We used to have more magic fields like these in other structures,
> like target_ops, for example.  IIRC, their intended purpose was to
> catch miscompilation, before we had Makefile auto-dependencies.  Before
> that, it was common to change the structure's definition, rebuild, and
> then find out that gdb hit a "failed internal consistency check" assertion,
> because some of the .o files hadn't been rebuilt to reflect the new layout.
> 
> For example, the target_ops magic said:
> 
>  /* Magic number for checking ops size.  If a struct doesn't end with this
>     number, somebody changed the declaration but didn't change all the
>     places that initialize one.  */
> 
>  #define        OPS_MAGIC       3840
> 
> With auto-dependencies, the problem this "solved" is largely a
> thing of the past.

Thanks for the explanation, that makes sense.

I assume you're happy that these days we should "assume a working
build system", and that if any errors like the above cropped up we
should fix those in the build dependencies, not by adding magic fields
to gdb.

Thanks,
Andrew
  

On 4/12/19 12:08 PM, Andrew Burgess wrote:
> * Pedro Alves <palves@redhat.com> [2019-04-12 10:50:00 +0100]:
> 
>> On 4/12/19 12:23 AM, Andrew Burgess wrote:
>>> The language_defn structure has an la_magic field, this used to be
>>> used as a basic check that the language_defn structure had the
>>> expected layout - at least the end of the structure was where we
>>> expected it to be.
>>>
>>> This feature only really makes sense if we imagine GDB dynamically
>>> loading language support from dynamic libraries, where a version
>>> mismatch might cause problems.
>>
>> We used to have more magic fields like these in other structures,
>> like target_ops, for example.  IIRC, their intended purpose was to
>> catch miscompilation, before we had Makefile auto-dependencies.  Before
>> that, it was common to change the structure's definition, rebuild, and
>> then find out that gdb hit a "failed internal consistency check" assertion,
>> because some of the .o files hadn't been rebuilt to reflect the new layout.
>>
>> For example, the target_ops magic said:
>>
>>  /* Magic number for checking ops size.  If a struct doesn't end with this
>>     number, somebody changed the declaration but didn't change all the
>>     places that initialize one.  */
>>
>>  #define        OPS_MAGIC       3840
>>
>> With auto-dependencies, the problem this "solved" is largely a
>> thing of the past.
> 
> Thanks for the explanation, that makes sense.
> 
> I assume you're happy that these days we should "assume a working
> build system", and that if any errors like the above cropped up we
> should fix those in the build dependencies, not by adding magic fields
> to gdb.

Yes, of course.  I was the one who removed OPS_MAGIC (in f6ac5f3d63e0)  :-)

Thanks,
Pedro Alves