Re: [rfa] Add a name field to ``struct floatformat''

[Andrew Cagney <ac131313@cygnus.com>]

Kevin Buettner wrote:
> 
> On May 31,  8:48am, Andrew Cagney wrote:
> 
> > Did you like how GDB added floatformat_to_double() to libiberty and then
> > replaced that with a local floatformat_to_doublest() ;-/
> 
> I noticed it, but did not know how it came about.  Who's responsible
> for maintaining libiberty?

Notionally GCC.  In reality, those specific files are (dig dig) only
used binutils (opcodes/m68k-dis.c) and gdb so we (gdb) are effectivly
responsibility them.  We would just have to make certain that all
changes are applied to GCC's master repository.

(To be honest, I'm guessing the history bit :-)

> The reason I ask is that I've been wondering what to do about the fact
> that we now have a number of fixes to floatformat_to_doublest() and
> floatformat_from_doublest() (or their helper functions) and that these
> have not (to the best of my knowledge) been merged into libiberty.
> 
> The ones that I know about are:
> 
>         * utils.c (get_field, put_field): Fix buffer underruns and
>         overruns.  Also, handle case where total_len is not evenly
>         divisible by 8.
>         (getfield): Make sure zeroing of unwanted bits occurs even
>         when bit field to extract does not straddle two or more
>         bytes.
> 
>         * utils.c (floatformat_from_doublest): Don't assume that a long
>         will be exactly 32 bits in length.  Also...  make sure space
>         that we're writing the float to is completely initialized to
>         zeroes, even when the number of bits in the float is not
>         evenly divisible by FLOATFORMAT_CHAR_BIT.

More outch!

	Andrew
From eliz@delorie.com Tue May 30 23:26:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [rfa/5] add PDF target to doc directory
Date: Tue, 30 May 2000 23:26:00 -0000
Message-id: <200005310626.CAA08713@indy.delorie.com>
References: <392F87DB.5E05556B@cygnus.com> <39306263.C6C5480D@cygnus.com> <3931EE33.D2EFAD6E@cygnus.com> <200005290719.DAA06087@indy.delorie.com> <39337A95.4E9DA83A@cygnus.com>
X-SW-Source: 2000-05/msg00477.html
Content-length: 290

> Date: Tue, 30 May 2000 18:23:49 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
>
> Yes,  I avoided ``@ifnottex'' which caused me grief last time.
> I've also tried it with makeinfo 3.12, 3.12f and 4.0 and they all went
> through without errors.

Then I think it's okay for the branch.
From eliz@delorie.com Wed May 31 00:06:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] PARAMS elimination - phase 2
Date: Wed, 31 May 2000 00:06:00 -0000
Message-id: <200005310705.DAA08769@indy.delorie.com>
References: <1000530232352.ZM5368@ocotillo.lan>
X-SW-Source: 2000-05/msg00478.html
Content-length: 1447

> Date: Tue, 30 May 2000 16:23:53 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> If you look carefully, you'll
> notice that there are a few places where other fields within a struct
> declaration have been reformatted.  I was torn between putting these
> fields back the way they were prior to running indent and leaving them
> in their newly indented state.  In the end I chose the latter option
> of leaving them in their newly indented state.
[snip]
> -void (*target_overlay_update) PARAMS ((struct obj_section *))
> -= simple_overlay_update;
> +void (*target_overlay_update) (struct obj_section *) = simple_overlay_update;
[snip]
> -static struct partial_symbol *lookup_partial_symbol PARAMS
> -  ((struct partial_symtab *, const char *,
> -    int, namespace_enum));
> +static struct partial_symbol *lookup_partial_symbol
> +  (struct partial_symtab *, const char *, int, namespace_enum);
[snip]
> -    struct target_ops
> -     *DONT_USE;			/* formerly to_next */
> +    struct target_ops *DONT_USE;	/* formerly to_next */

The above are a few of the examples of such a gratuitous
reformatting.  I think they are evil and should be avoided at all
costs.  They make it a PITA to apply patches sent by people who have
sources before the reformatting.  Introducing changes that merely
reshuffle white space really doesn't make sense to me.

I vote against those whitespace changes (even though these are not
files I'm responsible for).
From ac131313@cygnus.com Wed May 31 00:36:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] PARAMS elimination - phase 2
Date: Wed, 31 May 2000 00:36:00 -0000
Message-id: <3934C0D1.D8E8AB44@cygnus.com>
References: <1000530232352.ZM5368@ocotillo.lan>
X-SW-Source: 2000-05/msg00479.html
Content-length: 133

Kevin,

It probably shouldn't be touching the testsuite directory.  While GDB
might require ISO-C, the testsuite shouldn't.

	Andrew
From ac131313@cygnus.com Wed May 31 01:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] PARAMS elimination - phase 2
Date: Wed, 31 May 2000 01:00:00 -0000
Message-id: <3934C674.DBE2A089@cygnus.com>
References: <1000530232352.ZM5368@ocotillo.lan>
X-SW-Source: 2000-05/msg00480.html
Content-length: 2286

Kevin Buettner wrote:
> 
> Below are changes representing phase 2 of the campaign to purge the use
> of PARAMS from the gdb sources.

Can I suggest doing just the automated part of this change and then,
again, give the dust a chance to settle.  The remaining PARAMS that need
hand tweeking can then be done incrementally.

> posted earlier.  (It's identical but for one line.)  After running the
> script, the initial indent was incorrect for declarations appearing in
> structs and within the old pre-ansi parameter declarations.

Can the script remember how much leading white space there was and put
it back afterwards?

>  I fixed
> some of these initial indents by hand.  For the others, I reindented
> the struct declaration in which the declarations appeared.  (I used
> "indent -sbi2" since that seemed to be the convention for the brace
> placement after the struct keyword.) If you look carefully, you'll
> notice that there are a few places where other fields within a struct
> declaration have been reformatted.  I was torn between putting these
> fields back the way they were prior to running indent and leaving them
> in their newly indented state.  In the end I chose the latter option
> of leaving them in their newly indented state.  If you have concerns
> about this, please examine DONT_USE, to_sections, and to_sections_end
> in the patch to target.h below.

While a royal pain in the butt, if the process was automated it can be
lived with.  The main thing is that people with local sources can run
the script over them and preproduce your results.  Things to do include
rewrite target.h into something more like gdbarch.{h,c,sh}.

As an asside, the indent that was used had a bug with how it formatted
structs.  It would format them as either

	struct x
	  {
	    int i;
	  };

	struct x
	{
	  int i;
	};

> Andrew has recommended that I give a one day notice and then, unless
> there are objections, commit the changes.  So... unless I see objections
> to this patch before then, I plan to commit these changes tomorrow
> evening at around 5:00pm MST (which is midnight GMT of Thursday, June 1).

Oops, I was kind of thinking you would do the remainder by hand which
ment you would have been fixing things at the rate of one or two files a
day.  Sorry.

	Andrew
From ac131313@cygnus.com Wed May 31 01:05:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] PARAMS elimination - phase 2
Date: Wed, 31 May 2000 01:05:00 -0000
Message-id: <3934C781.F2FF9D1F@cygnus.com>
References: <1000530232352.ZM5368@ocotillo.lan> <200005310705.DAA08769@indy.delorie.com>
X-SW-Source: 2000-05/msg00481.html
Content-length: 1232

Eli Zaretskii wrote:
> 
> > Date: Tue, 30 May 2000 16:23:53 -0700
> > From: Kevin Buettner <kevinb@cygnus.com>
> >
> > If you look carefully, you'll
> > notice that there are a few places where other fields within a struct
> > declaration have been reformatted.  I was torn between putting these
> > fields back the way they were prior to running indent and leaving them
> > in their newly indented state.  In the end I chose the latter option
> > of leaving them in their newly indented state.
> [snip]
> > -void (*target_overlay_update) PARAMS ((struct obj_section *))
> > -= simple_overlay_update;
> > +void (*target_overlay_update) (struct obj_section *) = simple_overlay_update;
> [snip]
> > -static struct partial_symbol *lookup_partial_symbol PARAMS
> > -  ((struct partial_symtab *, const char *,
> > -    int, namespace_enum));
> > +static struct partial_symbol *lookup_partial_symbol
> > +  (struct partial_symtab *, const char *, int, namespace_enum);
> [snip]
> > -    struct target_ops
> > -     *DONT_USE;                      /* formerly to_next */
> > +    struct target_ops *DONT_USE;     /* formerly to_next */

In the case of the above, it doesn't worry me (I really am the target
vector maintainer :-).

	Andrew
From ac131313@cygnus.com Wed May 31 03:18:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: Update config.guess, config.sub, texinfo.tex
Date: Wed, 31 May 2000 03:18:00 -0000
Message-id: <3934E6D5.C2AEB97@cygnus.com>
References: <3931F0DF.868A3085@cygnus.com>
X-SW-Source: 2000-05/msg00482.html
Content-length: 201

Andrew Cagney wrote:
> 
> FYI,
> 
> I intend updating these with more recent copies from the official
> releases.  For texinfo.tex that would be makeinfo-4.0.

The texinfo.tex file is now in.

	Andrew
From blymn@baesystems.com.au Wed May 31 03:28:00 2000
From: blymn@baesystems.com.au (Brett Lymn)
To: gdb-patches@sourceware.cygnus.com
Subject: problem compiling gdb5.0 on NetBSD-current i386 ELF
Date: Wed, 31 May 2000 03:28:00 -0000
Message-id: <200005311028.TAA26612@mallee.awadi>
X-SW-Source: 2000-05/msg00483.html
Content-length: 6881

Folks,
        I just attempted to compile gdb5.0 on a NetBSD-current i386
ELF machine and the thing fell over compiling gdb/solib.c.  The uname
of my machine gives:

NetBSD siren 1.4X NetBSD 1.4X (SKEL) #0: Mon May 15 18:20:37 CST 2000
   toor@siren:/usr/src/sys/arch/i386/compile/SKEL i386

My gcc version is this:

gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

and the errors I get are these:

gmake[1]: Entering directory `/usr/local/src/gdb-5.0/libiberty'
gmake[2]: Entering directory `/usr/local/src/gdb-5.0/libiberty/testsuite'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/local/src/gdb-5.0/libiberty/testsuite'
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/libiberty'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/intl'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/intl'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/bfd'
gmake  all-recursive
gmake[2]: Entering directory `/usr/local/src/gdb-5.0/bfd'
Making all in doc
gmake[3]: Entering directory `/usr/local/src/gdb-5.0/bfd/doc'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/usr/local/src/gdb-5.0/bfd/doc'
Making all in po
gmake[3]: Entering directory `/usr/local/src/gdb-5.0/bfd/po'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/usr/local/src/gdb-5.0/bfd/po'
gmake[3]: Entering directory `/usr/local/src/gdb-5.0/bfd'
gmake[3]: Nothing to be done for `all-am'.
gmake[3]: Leaving directory `/usr/local/src/gdb-5.0/bfd'
gmake[2]: Leaving directory `/usr/local/src/gdb-5.0/bfd'
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/bfd'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/opcodes'
gmake  all-recursive
gmake[2]: Entering directory `/usr/local/src/gdb-5.0/opcodes'
Making all in po
gmake[3]: Entering directory `/usr/local/src/gdb-5.0/opcodes/po'
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/usr/local/src/gdb-5.0/opcodes/po'
gmake[3]: Entering directory `/usr/local/src/gdb-5.0/opcodes'
gmake[3]: Nothing to be done for `all-am'.
gmake[3]: Leaving directory `/usr/local/src/gdb-5.0/opcodes'
gmake[2]: Leaving directory `/usr/local/src/gdb-5.0/opcodes'
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/opcodes'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/etc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/etc'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/mmalloc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/mmalloc'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/readline'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/readline'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/sim'
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/sim'
gmake[1]: Entering directory `/usr/local/src/gdb-5.0/gdb'
gcc -c -g -O2    -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl -I./tui  -DUSE_INCLUDED_REGEX   solib.c
solib.c: In function `solib_map_sections':
solib.c:369: structure has no member named `som_addr'
solib.c:369: structure has no member named `som_addr'
solib.c:370: structure has no member named `som_addr'
solib.c:370: structure has no member named `som_addr'
solib.c: In function `solib_add_common_symbols':
solib.c:431: storage size of `inferior_rtc_symb' isn't known
solib.c: In function `first_link_map_member':
solib.c:896: sizeof applied to an incomplete type
solib.c:897: invalid use of undefined type `struct _dynamic'
solib.c:901: invalid use of undefined type `struct _dynamic'
solib.c:901: invalid use of undefined type `struct _dynamic'
solib.c:902: sizeof applied to an incomplete type
solib.c:903: invalid use of undefined type `struct section_dispatch_table'
solib.c:903: invalid use of undefined type `struct section_dispatch_table'
solib.c: In function `current_sos':
solib.c:1099: structure has no member named `som_next'
solib.c:1099: structure has no member named `som_next'
solib.c:1114: structure has no member named `som_path'
solib.c:1114: structure has no member named `som_path'
solib.c: In function `symbol_add_stub':
solib.c:1181: structure has no member named `som_addr'
solib.c:1181: structure has no member named `som_addr'
solib.c: In function `info_sharedlibrary_command':
solib.c:1508: structure has no member named `som_addr'
solib.c:1508: structure has no member named `som_addr'
solib.c: In function `solib_address':
solib.c:1555: structure has no member named `som_addr'
solib.c:1555: structure has no member named `som_addr'
solib.c: In function `disable_break':
solib.c:1662: sizeof applied to an incomplete type
solib.c:1668: invalid use of undefined type `struct so_debug'
solib.c:1668: invalid use of undefined type `struct so_debug'
solib.c:1669: invalid use of undefined type `struct so_debug'
solib.c:1670: invalid use of undefined type `struct so_debug'
solib.c: In function `enable_break':
solib.c:1754: sizeof applied to an incomplete type
solib.c:1763: invalid use of undefined type `struct _dynamic'
solib.c:1763: invalid use of undefined type `struct _dynamic'
solib.c:1767: invalid use of undefined type `struct so_debug'
solib.c: In function `special_symbol_handling':
solib.c:2053: sizeof applied to an incomplete type
solib.c:2064: invalid use of undefined type `struct _dynamic'
solib.c:2064: invalid use of undefined type `struct _dynamic'
solib.c:2071: sizeof applied to an incomplete type
solib.c:2077: invalid use of undefined type `struct so_debug'
solib.c:2079: invalid use of undefined type `struct so_debug'
solib.c:2079: invalid use of undefined type `struct so_debug'
solib.c: At top level:
solib.c:128: storage size of `dynamic_copy' isn't known
solib.c:129: storage size of `ld_2_copy' isn't known
solib.c:130: storage size of `debug_copy' isn't known
gmake[1]: *** [solib.o] Error 1
gmake[1]: Leaving directory `/usr/local/src/gdb-5.0/gdb'
gmake: *** [all-gdb] Error 2


The interesting thing about this is if I look at the lines that have
the error about som_addr on them I see this:

      p->addr += LM_ADDR (so);

which use these defines from the top of the file:

#define SOLIB_EXTRACT_ADDRESS(member) \
  extract_address (&member, sizeof (member))

#ifndef SVR4_SHARED_LIBS

#define LM_ADDR(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_addr))


_but_ if I look at the preprocessor output I see:

      p->addr += (extract_address (& ( so ) -> lm. som_addr  , sizeof
( ( so ) -> lm. som_addr  )) ) ;


somehow the lm_addr's have been changed into som_addr which is very odd.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================