From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Kevin Buettner Cc: GDB Patches , Nick Clifton Subject: Re: [rfa] Add a name field to ``struct floatformat'' Date: Tue, 30 May 2000 19:18:00 -0000 Message-id: <39347623.A1FCF461@cygnus.com> References: <3933676F.676D861C@cygnus.com> <1000530153706.ZM32196@ocotillo.lan> <3934454E.AAB68F28@cygnus.com> <1000530234235.ZM5405@ocotillo.lan> X-SW-Source: 2000-05/msg00476.html 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 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 > > 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 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 > > 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 To: Kevin Buettner 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 To: Kevin Buettner 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 To: Eli Zaretskii 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 > > > > 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 To: BINUTILS Patches , GDB Patches 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 ===============================================================================