From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Brian Youmans <3diff@gnu.org> Cc: fnasser@cygnus.com, dj@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: authorship Date: Wed, 10 May 2000 18:25:00 -0000 Message-id: <391A0BA8.12B6D57C@cygnus.com> References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> <200005081637.MAA18610@envy.delorie.com> <3916F261.EB8FAD0C@cygnus.com> <200005081809.OAA20154@delysid.gnu.org> X-SW-Source: 2000-05/msg00168.html Brian Youmans wrote: > > RMS thinks "Richard Stallman, Roland Pesch, Stan Shebs, et al." is a > good idea. I still like "and others", but I'm willing to compromise. > If there are no objections, I will implement that here on our printed > manuals, asnd someone should implement it in gdb.texinfo. > > After that, I will go ahead and print the manual, and stop pestering > the list. To go out on a limb, the front page could simply note ``The Free Software Foundation'' or ``The GDB Community'' with an internal page listing the contributors (companies and individuals) for each version. However, I suspect Richard, Roland and Stan et.al. is good enough. > Is there a present target for GDB 5 release? This and a threads nuance are all that I'm aware of as issues. Yesterday? More seriously < two weeks. I'm in the process of rolling 4.95.1. Andrew >From ac131313@cygnus.com Wed May 10 20:38:00 2000 From: Andrew Cagney To: GDB Patches Subject: [patch] Add preliminary support for IRIX n32 multi-arch Date: Wed, 10 May 2000 20:38:00 -0000 Message-id: <391A2AE2.7289FEC5@cygnus.com> X-SW-Source: 2000-05/msg00169.html Content-length: 16045 Hello, The attatched patch adds preliminary support for the IRIX n32 ABI to the MIPS multi-arch framework. Testing suggests it mostly works. As the comment notes, there is currently one additional regression. Andrew Thu May 11 13:24:52 2000 Andrew Cagney * mips-tdep.c (MIPS_DEFAULT_STACK_ARGSIZE): Fix typo. * config/mips/tm-irix5.h (GDB_MULTI_ARCH): Add definition. Disable. Document known problems. (MIPS_DEFAULT_ABI): Define. * mips-tdep.c (enum mips_abi): Define. (struct gdbarch_tdep): Replace mips_eabi with mips_abi. (MIPS_EABI): Update. (mips_gdbarch_init): Add preliminary support for IRIX N32 ABI. Determine ABI from either ELF_FLAGS or MIPS_DEFAULT_ABI. When looking for a matching architecture require a matching MIPS_ABI. (mips_gdbarch_init): Cleanup arch_debug information. Index: mips-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/mips-tdep.c,v retrieving revision 1.6 diff -p -r1.6 mips-tdep.c *** mips-tdep.c 2000/05/08 02:53:04 1.6 --- mips-tdep.c 2000/05/11 03:32:24 *************** *** 40,45 **** --- 40,57 ---- #include "elf-bfd.h" + /* All the possible MIPS ABIs. */ + + enum mips_abi + { + MIPS_ABI_UNKNOWN, + MIPS_ABI_N32, + MIPS_ABI_O32, + MIPS_ABI_O64, + MIPS_ABI_EABI32, + MIPS_ABI_EABI64 + }; + struct frame_extra_info { mips_extra_func_info_t proc_desc; *************** struct gdbarch_tdep *** 91,97 **** /* from the elf header */ int elf_flags; /* mips options */ ! int mips_eabi; enum mips_fpu_type mips_fpu_type; int mips_last_arg_regnum; int mips_last_fp_arg_regnum; --- 103,109 ---- /* from the elf header */ int elf_flags; /* mips options */ ! enum mips_abi mips_abi; enum mips_fpu_type mips_fpu_type; int mips_last_arg_regnum; int mips_last_fp_arg_regnum; *************** struct gdbarch_tdep *** 103,109 **** #if GDB_MULTI_ARCH #undef MIPS_EABI ! #define MIPS_EABI (gdbarch_tdep (current_gdbarch)->mips_eabi) #endif #if GDB_MULTI_ARCH --- 115,122 ---- #if GDB_MULTI_ARCH #undef MIPS_EABI ! #define MIPS_EABI (gdbarch_tdep (current_gdbarch)->mips_abi == MIPS_ABI_EABI32 \ ! || gdbarch_tdep (current_gdbarch)->mips_abi == MIPS_ABI_EABI32) #endif #if GDB_MULTI_ARCH *************** mips_saved_regsize () *** 171,177 **** #if GDB_MULTI_ARCH #undef MIPS_DEFAULT_STACK_ARGSIZE ! #define MIPS_DEFAULT_STACK_ARGSIZE (gdbarch_tdep (current_gdbarch)->mips_default_statck_argsize) #elif !defined (MIPS_DEFAULT_STACK_ARGSIZE) #define MIPS_DEFAULT_STACK_ARGSIZE (MIPS_DEFAULT_SAVED_REGSIZE) #endif --- 184,190 ---- #if GDB_MULTI_ARCH #undef MIPS_DEFAULT_STACK_ARGSIZE ! #define MIPS_DEFAULT_STACK_ARGSIZE (gdbarch_tdep (current_gdbarch)->mips_default_stack_argsize) #elif !defined (MIPS_DEFAULT_STACK_ARGSIZE) #define MIPS_DEFAULT_STACK_ARGSIZE (MIPS_DEFAULT_SAVED_REGSIZE) #endif *************** mips_gdbarch_init (info, arches) *** 3753,3758 **** --- 3766,3772 ---- char *ef_mips_abi; int ef_mips_bitptrs; int ef_mips_arch; + enum mips_abi mips_abi; /* Extract the elf_flags if available */ if (info.abfd != NULL *************** mips_gdbarch_init (info, arches) *** 3761,3766 **** --- 3775,3804 ---- else elf_flags = 0; + /* Check ELF_FLAGS to see if it specifies the ABI being used. */ + switch ((elf_flags & EF_MIPS_ABI)) + { + case E_MIPS_ABI_O32: + mips_abi = MIPS_ABI_O32; + break; + case E_MIPS_ABI_O64: + mips_abi = MIPS_ABI_O64; + break; + case E_MIPS_ABI_EABI32: + mips_abi = MIPS_ABI_EABI32; + break; + case E_MIPS_ABI_EABI64: + mips_abi = MIPS_ABI_EABI32; + break; + default: + mips_abi = MIPS_ABI_UNKNOWN; + break; + } + #ifdef MIPS_DEFAULT_ABI + if (mips_abi == MIPS_ABI_UNKNOWN) + mips_abi = MIPS_DEFAULT_ABI; + #endif + /* try to find a pre-existing architecture */ for (arches = gdbarch_list_lookup_by_info (arches, &info); arches != NULL; *************** mips_gdbarch_init (info, arches) *** 3770,3775 **** --- 3808,3815 ---- using. */ if (gdbarch_tdep (current_gdbarch)->elf_flags != elf_flags) continue; + if (gdbarch_tdep (current_gdbarch)->mips_abi != mips_abi) + continue; return arches->gdbarch; } *************** mips_gdbarch_init (info, arches) *** 3784,3838 **** set_gdbarch_float_bit (gdbarch, 32); set_gdbarch_double_bit (gdbarch, 64); set_gdbarch_long_double_bit (gdbarch, 64); ! switch ((elf_flags & EF_MIPS_ABI)) { ! case E_MIPS_ABI_O32: ef_mips_abi = "o32"; - tdep->mips_eabi = 0; tdep->mips_default_saved_regsize = 4; tdep->mips_fp_register_double = 0; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; ! case E_MIPS_ABI_O64: ef_mips_abi = "o64"; - tdep->mips_eabi = 0; tdep->mips_default_saved_regsize = 8; tdep->mips_fp_register_double = 1; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; ! case E_MIPS_ABI_EABI32: ef_mips_abi = "eabi32"; - tdep->mips_eabi = 1; tdep->mips_default_saved_regsize = 4; tdep->mips_fp_register_double = 0; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; ! case E_MIPS_ABI_EABI64: ef_mips_abi = "eabi64"; - tdep->mips_eabi = 1; tdep->mips_default_saved_regsize = 8; tdep->mips_fp_register_double = 1; set_gdbarch_long_bit (gdbarch, 64); set_gdbarch_ptr_bit (gdbarch, 64); set_gdbarch_long_long_bit (gdbarch, 64); break; default: ef_mips_abi = "default"; - tdep->mips_eabi = 0; tdep->mips_default_saved_regsize = MIPS_REGSIZE; tdep->mips_fp_register_double = (REGISTER_VIRTUAL_SIZE (FP0_REGNUM) == 8); set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; } - tdep->mips_default_stack_argsize = tdep->mips_default_saved_regsize; /* FIXME: jlarmour/2000-04-07: There *is* a flag EF_MIPS_32BIT_MODE that could indicate -gp32 BUT gas/config/tc-mips.c contains the --- 3824,3905 ---- set_gdbarch_float_bit (gdbarch, 32); set_gdbarch_double_bit (gdbarch, 64); set_gdbarch_long_double_bit (gdbarch, 64); ! tdep->mips_abi = mips_abi; ! switch (mips_abi) { ! case MIPS_ABI_O32: ef_mips_abi = "o32"; tdep->mips_default_saved_regsize = 4; + tdep->mips_default_stack_argsize = 4; tdep->mips_fp_register_double = 0; + tdep->mips_last_arg_regnum = ZERO_REGNUM + 7; + tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 15; + tdep->mips_regs_have_home_p = 1; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; ! case MIPS_ABI_O64: ef_mips_abi = "o64"; tdep->mips_default_saved_regsize = 8; + tdep->mips_default_stack_argsize = 8; tdep->mips_fp_register_double = 1; + tdep->mips_last_arg_regnum = ZERO_REGNUM + 7; + tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 15; + tdep->mips_regs_have_home_p = 1; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; ! case MIPS_ABI_EABI32: ef_mips_abi = "eabi32"; tdep->mips_default_saved_regsize = 4; + tdep->mips_default_stack_argsize = 4; tdep->mips_fp_register_double = 0; + tdep->mips_last_arg_regnum = ZERO_REGNUM + 11; + tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 19; + tdep->mips_regs_have_home_p = 0; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; ! case MIPS_ABI_EABI64: ef_mips_abi = "eabi64"; tdep->mips_default_saved_regsize = 8; + tdep->mips_default_stack_argsize = 8; tdep->mips_fp_register_double = 1; + tdep->mips_last_arg_regnum = ZERO_REGNUM + 11; + tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 19; + tdep->mips_regs_have_home_p = 0; set_gdbarch_long_bit (gdbarch, 64); set_gdbarch_ptr_bit (gdbarch, 64); set_gdbarch_long_long_bit (gdbarch, 64); break; + case MIPS_ABI_N32: + ef_mips_abi = "n32"; + tdep->mips_default_saved_regsize = 4; + tdep->mips_default_stack_argsize = 8; + tdep->mips_fp_register_double = 1; + tdep->mips_last_arg_regnum = ZERO_REGNUM + 11; + tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 19; + tdep->mips_regs_have_home_p = 0; + set_gdbarch_long_bit (gdbarch, 32); + set_gdbarch_ptr_bit (gdbarch, 32); + set_gdbarch_long_long_bit (gdbarch, 64); + break; default: ef_mips_abi = "default"; tdep->mips_default_saved_regsize = MIPS_REGSIZE; + tdep->mips_default_stack_argsize = MIPS_REGSIZE; tdep->mips_fp_register_double = (REGISTER_VIRTUAL_SIZE (FP0_REGNUM) == 8); + tdep->mips_last_arg_regnum = ZERO_REGNUM + 11; + tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 19; + tdep->mips_regs_have_home_p = 1; set_gdbarch_long_bit (gdbarch, 32); set_gdbarch_ptr_bit (gdbarch, 32); set_gdbarch_long_long_bit (gdbarch, 64); break; } /* FIXME: jlarmour/2000-04-07: There *is* a flag EF_MIPS_32BIT_MODE that could indicate -gp32 BUT gas/config/tc-mips.c contains the *************** mips_gdbarch_init (info, arches) *** 3890,3915 **** } #endif - /* Select either of the two alternative ABI's */ - if (tdep->mips_eabi) - { - /* EABI uses R4 through R11 for args */ - tdep->mips_last_arg_regnum = 11; - /* EABI uses F12 through F19 for args */ - tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 19; - /* EABI does not reserve home space for registers */ - tdep->mips_regs_have_home_p = 0; - } - else - { - /* old ABI uses R4 through R7 for args */ - tdep->mips_last_arg_regnum = 7; - /* old ABI uses F12 through F15 for args */ - tdep->mips_last_fp_arg_regnum = FP0_REGNUM + 15; - /* Old ABI reserves home space for registers */ - tdep->mips_regs_have_home_p = 1; - } - /* enable/disable the MIPS FPU */ if (!mips_fpu_type_auto) tdep->mips_fpu_type = mips_fpu_type; --- 3957,3962 ---- *************** mips_gdbarch_init (info, arches) *** 3967,4008 **** if (gdbarch_debug) { ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: (info)elf_flags = 0x%x\n", ! elf_flags); ! fprintf_unfiltered (gdb_stderr, "mips_gdbarch_init: (info)ef_mips_abi = %s\n", ef_mips_abi); ! fprintf_unfiltered (gdb_stderr, "mips_gdbarch_init: (info)ef_mips_arch = %d\n", ef_mips_arch); ! fprintf_unfiltered (gdb_stderr, "mips_gdbarch_init: (info)ef_mips_bitptrs = %d\n", ef_mips_bitptrs); ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: MIPS_EABI = %d\n", ! tdep->mips_eabi); ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: MIPS_LAST_ARG_REGNUM = %d\n", ! tdep->mips_last_arg_regnum); ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: MIPS_LAST_FP_ARG_REGNUM = %d (%d)\n", ! tdep->mips_last_fp_arg_regnum, ! tdep->mips_last_fp_arg_regnum - FP0_REGNUM); ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: tdep->mips_fpu_type = %d (%s)\n", tdep->mips_fpu_type, (tdep->mips_fpu_type == MIPS_FPU_NONE ? "none" ! : tdep->mips_fpu_type == MIPS_FPU_SINGLE ? "single" ! : tdep->mips_fpu_type == MIPS_FPU_DOUBLE ? "double" : "???")); ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: tdep->mips_default_saved_regsize = %d\n", tdep->mips_default_saved_regsize); ! fprintf_unfiltered (gdb_stderr, ! "mips_gdbarch_init: tdep->mips_fp_register_double = %d (%s)\n", tdep->mips_fp_register_double, ! (tdep->mips_fp_register_double ? "true" : "false")); } return gdbarch; --- 4014,4064 ---- if (gdbarch_debug) { ! fprintf_unfiltered (gdb_stdlog, "mips_gdbarch_init: (info)ef_mips_abi = %s\n", ef_mips_abi); ! fprintf_unfiltered (gdb_stdlog, "mips_gdbarch_init: (info)ef_mips_arch = %d\n", ef_mips_arch); ! fprintf_unfiltered (gdb_stdlog, "mips_gdbarch_init: (info)ef_mips_bitptrs = %d\n", ef_mips_bitptrs); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: MIPS_REGSIZE = %d\n", ! MIPS_REGSIZE); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->elf_flags = 0x%x\n", ! tdep->elf_flags); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_abi = %d\n", ! tdep->mips_abi); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_fpu_type = %d (%s)\n", tdep->mips_fpu_type, (tdep->mips_fpu_type == MIPS_FPU_NONE ? "none" ! : tdep->mips_fpu_type == MIPS_FPU_SINGLE ? "single" ! : tdep->mips_fpu_type == MIPS_FPU_DOUBLE ? "double" : "???")); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_last_arg_regnum = %d\n", ! tdep->mips_last_arg_regnum); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_last_fp_arg_regnum = %d (%d)\n", ! tdep->mips_last_fp_arg_regnum, ! tdep->mips_last_fp_arg_regnum - FP0_REGNUM); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_default_saved_regsize = %d\n", tdep->mips_default_saved_regsize); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_fp_register_double = %d (%s)\n", tdep->mips_fp_register_double, ! (tdep->mips_fp_register_double ? "true" : "false")); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_regs_have_home_p = %d\n", ! tdep->mips_regs_have_home_p); ! fprintf_unfiltered (gdb_stdlog, ! "mips_gdbarch_init: tdep->mips_default_stack_argsize = %d\n", ! tdep->mips_default_stack_argsize); } return gdbarch; Index: config/mips/tm-irix5.h =================================================================== RCS file: /cvs/src/src/gdb/config/mips/tm-irix5.h,v retrieving revision 1.3 diff -p -r1.3 tm-irix5.h *** tm-irix5.h 2000/05/08 02:53:04 1.3 --- tm-irix5.h 2000/05/11 03:32:26 *************** *** 18,23 **** --- 18,34 ---- Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ + /* If we're being built for n32, enable multi-arch. */ + /* FIXME: cagney/2000-04-04: Testing the _MIPS_SIM_NABI32 and + _MIPS_SIM in a tm-*.h file is simply wrong! Those are + host-dependant macros (provided by /usr/include) and stop any + chance of the target being cross compiled */ + #if 0 && defined (_MIPS_SIM_NABI32) && _MIPS_SIM == _MIPS_SIM_NABI32 + /* FIXME: Don't enable multi-arch for IRIX/n32. The test + ``gdb.base/corefile.exp: up in corefile.exp'' fails. */ + #define GDB_MULTI_ARCH 1 + #endif + #include "mips/tm-irix3.h" /* FIXME: cagney/2000-04-04: Testing the _MIPS_SIM_NABI32 and *************** *** 58,63 **** --- 69,77 ---- /* N32 does not reserve home space for registers used to carry parameters. */ #define MIPS_REGS_HAVE_HOME_P 0 + + /* Force N32 ABI as the default. */ + #define MIPS_DEFAULT_ABI MIPS_ABI_N32 #endif /* N32 */ >From ac131313@cygnus.com Thu May 11 00:53:00 2000 From: Andrew Cagney To: GDB Patches Subject: [patch/5] README Date: Thu, 11 May 2000 00:53:00 -0000 Message-id: <391A66C3.475F9B2D@cygnus.com> X-SW-Source: 2000-05/msg00170.html Content-length: 31720 FYI, I've committed the attached. It updates the file gdb/README. Andrew Thu May 11 17:22:36 2000 Andrew Cagney * README: Update for GDB 5.0. Index: README =================================================================== RCS file: /cvs/src/src/gdb/README,v retrieving revision 1.1.1.2.2.2 diff -p -r1.1.1.2.2.2 README *** README 2000/05/11 00:32:18 1.1.1.2.2.2 --- README 2000/05/11 07:51:22 *************** *** 1,5 **** ! README for gdb-4.18 release ! Updated 4 Apr 1999 by Jim Blandy This is GDB, the GNU source-level debugger. A summary of new features is in the file `NEWS'. --- 1,5 ---- ! README for gdb-5.0 release ! Updated 11 May 2000 by Andrew Cagney This is GDB, the GNU source-level debugger. A summary of new features is in the file `NEWS'. *************** date release information, mailing list l *** 11,20 **** Unpacking and Installation -- quick overview ========================== ! In this release, the GDB debugger sources, the generic GNU include files, the BFD ("binary file description") library, the readline library, and other libraries all have directories of their own ! underneath the gdb-4.18 directory. The idea is that a variety of GNU tools can share a common copy of these things. Be aware of variation over time--for example don't try to build gdb with a copy of bfd from a release other than the gdb release (such as a binutils or gas --- 11,20 ---- Unpacking and Installation -- quick overview ========================== ! In this release, the GDB debugger sources, the generic GNU include files, the BFD ("binary file description") library, the readline library, and other libraries all have directories of their own ! underneath the gdb-5.0 directory. The idea is that a variety of GNU tools can share a common copy of these things. Be aware of variation over time--for example don't try to build gdb with a copy of bfd from a release other than the gdb release (such as a binutils or gas *************** Configuration scripts and makefiles exis *** 23,89 **** directory tree and automatically build all the pieces in the right order. ! When you unpack the gdb-4.18.tar.gz file, you'll find a directory ! called `gdb-4.18', which contains: ! COPYING config.sub* libiberty/ opcodes/ ! COPYING.LIB configure* mmalloc/ readline/ ! Makefile.in configure.in move-if-change* sim/ ! README etc/ mpw-README texinfo/ ! bfd/ gdb/ mpw-build.in utils/ ! config/ include/ mpw-config.in ! config.guess* install.sh* mpw-configure To build GDB, you can just do: ! cd gdb-4.18 ./configure make cp gdb/gdb /usr/local/bin/gdb (or wherever you want) (Building GDB with DJGPP tools for MS-DOS/MS-Windows is slightly ! different; see the file gdb/config/djgpp/README for details.) ! This will configure and build all the libraries as well as GDB. ! If `configure' can't determine your system type, specify one as its ! argument, e.g., sun4 or decstation. ! ! If you get compiler warnings during this stage, see the `Reporting Bugs' ! section below; there are a few known problems. ! ! GDB requires an ANSI C compiler. If you do not have an ANSI C ! compiler for your system, you may be able to download and install the ! GNU CC compiler. It is available via anonymous FTP from ftp.gnu.org, ! in /pub/gnu/gcc (as a URL, that's ftp://ftp.gnu.org/pub/gnu/gcc ). - GDB can be used as a cross-debugger, running on a machine of one type - while debugging a program running on a machine of another type. See below. - More Documentation ****************** All the documentation for GDB comes as part of the machine-readable ! distribution. The documentation is written in Texinfo format, which is ! a documentation system that uses a single source file to produce both ! on-line information and a printed manual. You can use one of the Info ! formatting commands to create the on-line version of the documentation ! and TeX (or `texi2roff') to typeset the printed version. ! ! GDB includes an already formatted copy of the on-line Info version of ! this manual in the `gdb/doc' subdirectory. The main Info file is ! `gdb-4.18/gdb/doc/gdb.info', and it refers to subordinate files matching ! `gdb.info*' in the same directory. If necessary, you can print out ! these files, or read them with any editor; but they are easier to read ! using the `info' subsystem in GNU Emacs or the standalone `info' program, ! available as part of the GNU Texinfo distribution. If you want to format these Info files yourself, you need one of the Info formatting programs, such as `texinfo-format-buffer' or `makeinfo'. If you have `makeinfo' installed, and are in the top level GDB ! source directory (`gdb-4.18', in the case of version 4.18), you can make the Info file by typing: cd gdb/doc --- 23,92 ---- directory tree and automatically build all the pieces in the right order. ! When you unpack the gdb-5.0.tar.gz file, you'll find a directory ! called `gdb-5.0', which contains: ! COPYING config.if install-sh mmalloc readline ! COPYING.LIB config.sub intl move-if-change sim ! Makefile.in configure libiberty mpw-README symlink-tree ! README configure.in ltconfig mpw-build.in texinfo ! bfd djunpack.bat ltmain.sh mpw-config.in utils ! config etc md5.sum mpw-configure ylwrap ! config-ml.in gdb missing mpw-install ! config.guess include mkinstalldirs opcodes To build GDB, you can just do: ! cd gdb-5.0 ./configure make cp gdb/gdb /usr/local/bin/gdb (or wherever you want) (Building GDB with DJGPP tools for MS-DOS/MS-Windows is slightly ! different; see the file gdb-5.0/gdb/config/djgpp/README for details.) ! This will configure and build all the libraries as well as GDB. If ! `configure' can't determine your system type, specify one as its ! argument, e.g., `./configure sun4' or `./configure decstation'. ! ! If you get compiler errors during this stage, see the `Reporting ! Bugs' section below; there are a few known problems. ! ! GDB requires an ISO-C (ANSI C) compiler. If you do not have an ! ISO-C compiler for your system, you may be able to download and ! install the GNU CC compiler. It is available via anonymous FTP from ! the directory ` ftp://ftp.gnu.org/pub/gnu/gcc '. ! ! GDB can be used as a cross-debugger, running on a machine of one ! type while debugging a program running on a machine of another type. ! See below. More Documentation ****************** All the documentation for GDB comes as part of the machine-readable ! distribution. The documentation is written in Texinfo format, which ! is a documentation system that uses a single source file to produce ! both on-line information and a printed manual. You can use one of the ! Info formatting commands to create the on-line version of the ! documentation and TeX (or `texi2roff') to typeset the printed version. ! ! GDB includes an already formatted copy of the on-line Info version ! of this manual in the `gdb/doc' subdirectory. The main Info file is ! `gdb-5.0/gdb/doc/gdb.info', and it refers to subordinate files ! matching `gdb.info*' in the same directory. If necessary, you can ! print out these files, or read them with any editor; but they are ! easier to read using the `info' subsystem in GNU Emacs or the ! standalone `info' program, available as part of the GNU Texinfo ! distribution. If you want to format these Info files yourself, you need one of the Info formatting programs, such as `texinfo-format-buffer' or `makeinfo'. If you have `makeinfo' installed, and are in the top level GDB ! source directory (`gdb-5.0', in the case of version 5.0), you can make the Info file by typing: cd gdb/doc *************** the Info file by typing: *** 92,98 **** If you want to typeset and print copies of this manual, you need TeX, a program to print its DVI output files, and `texinfo.tex', the Texinfo definitions file. This file is included in the GDB ! distribution, in the directory `gdb-4.18/texinfo'. TeX is a typesetting program; it does not print files directly, but produces output files called DVI files. To print a typeset document, --- 95,101 ---- If you want to typeset and print copies of this manual, you need TeX, a program to print its DVI output files, and `texinfo.tex', the Texinfo definitions file. This file is included in the GDB ! distribution, in the directory `gdb-5.0/texinfo'. TeX is a typesetting program; it does not print files directly, but produces output files called DVI files. To print a typeset document, *************** without any extension or a `.dvi' extens *** 106,116 **** This file tells TeX how to typeset a document written in Texinfo format. On its own, TeX cannot read, much less typeset a Texinfo file. `texinfo.tex' is distributed with GDB and is located in the ! `gdb-4.18/texinfo' directory. If you have TeX and a DVI printer program installed, you can typeset and print this manual. First switch to the the `gdb' subdirectory of ! the main source directory (for example, to `gdb-4.18/gdb') and then type: make gdb.dvi --- 109,119 ---- This file tells TeX how to typeset a document written in Texinfo format. On its own, TeX cannot read, much less typeset a Texinfo file. `texinfo.tex' is distributed with GDB and is located in the ! `gdb-5.0/texinfo' directory. If you have TeX and a DVI printer program installed, you can typeset and print this manual. First switch to the the `gdb' subdirectory of ! the main source directory (for example, to `gdb-5.0/gdb') and then type: make gdb.dvi *************** preparing GDB for installation; you can *** 126,180 **** a single directory, whose name is usually composed by appending the version number to `gdb'. ! For example, the GDB version 4.18 distribution is in the `gdb-4.18' directory. That directory contains: ! `gdb-4.18/{COPYING,COPYING.LIB}' Standard GNU license files. Please read them. ! `gdb-4.18/bfd' source for the Binary File Descriptor library ! `gdb-4.18/config*' script for configuring GDB, along with other support files ! `gdb-4.18/gdb' the source specific to GDB itself ! `gdb-4.18/include' GNU include files ! `gdb-4.18/libiberty' source for the `-liberty' free software library ! `gdb-4.18/mmalloc' source for the GNU memory-mapped malloc package ! `gdb-4.18/opcodes' source for the library of opcode tables and disassemblers ! `gdb-4.18/readline' source for the GNU command-line interface NOTE: The readline library is compiled for use by GDB, but will not be installed on your system when "make install" is issued. ! `gdb-4.18/sim' source for some simulators (ARM, D10V, SPARC, M32R, MIPS, PPC, V850, etc) ! `gdb-4.18/intl' source for the GNU gettext library, for internationalization. This is slightly modified from the standalone gettext distribution you can get from GNU. ! `gdb-4.18/texinfo' The `texinfo.tex' file, which you need in order to make a printed manual using TeX. ! `gdb-4.18/etc' Coding standards, useful files for editing GDB, and other miscellanea. ! `gdb-4.18/utils' A grab bag of random utilities. Note: the following instructions are for building GDB on Unix or --- 129,183 ---- a single directory, whose name is usually composed by appending the version number to `gdb'. ! For example, the GDB version 5.0 distribution is in the `gdb-5.0' directory. That directory contains: ! `gdb-5.0/{COPYING,COPYING.LIB}' Standard GNU license files. Please read them. ! `gdb-5.0/bfd' source for the Binary File Descriptor library ! `gdb-5.0/config*' script for configuring GDB, along with other support files ! `gdb-5.0/gdb' the source specific to GDB itself ! `gdb-5.0/include' GNU include files ! `gdb-5.0/libiberty' source for the `-liberty' free software library ! `gdb-5.0/mmalloc' source for the GNU memory-mapped malloc package ! `gdb-5.0/opcodes' source for the library of opcode tables and disassemblers ! `gdb-5.0/readline' source for the GNU command-line interface NOTE: The readline library is compiled for use by GDB, but will not be installed on your system when "make install" is issued. ! `gdb-5.0/sim' source for some simulators (ARM, D10V, SPARC, M32R, MIPS, PPC, V850, etc) ! `gdb-5.0/intl' source for the GNU gettext library, for internationalization. This is slightly modified from the standalone gettext distribution you can get from GNU. ! `gdb-5.0/texinfo' The `texinfo.tex' file, which you need in order to make a printed manual using TeX. ! `gdb-5.0/etc' Coding standards, useful files for editing GDB, and other miscellanea. ! `gdb-5.0/utils' A grab bag of random utilities. Note: the following instructions are for building GDB on Unix or *************** MS-DOS/MS-Windows are in the file gdb/co *** 183,196 **** The simplest way to configure and build GDB is to run `configure' from the `gdb-VERSION-NUMBER' source directory, which in this example ! is the `gdb-4.18' directory. First switch to the `gdb-VERSION-NUMBER' source directory if you are not already in it; then run `configure'. For example: ! cd gdb-4.18 ./configure make --- 186,199 ---- The simplest way to configure and build GDB is to run `configure' from the `gdb-VERSION-NUMBER' source directory, which in this example ! is the `gdb-5.0' directory. First switch to the `gdb-VERSION-NUMBER' source directory if you are not already in it; then run `configure'. For example: ! cd gdb-5.0 ./configure make *************** you may need to run `sh' on it explicitl *** 206,213 **** sh configure If you run `configure' from a directory that contains source ! directories for multiple libraries or programs, such as the `gdb-4.18' ! source directory for version 4.18, `configure' creates configuration files for every directory level underneath (unless you tell it not to, with the `--norecursion' option). --- 209,216 ---- sh configure If you run `configure' from a directory that contains source ! directories for multiple libraries or programs, such as the `gdb-5.0' ! source directory for version 5.0, `configure' creates configuration files for every directory level underneath (unless you tell it not to, with the `--norecursion' option). *************** with the `--norecursion' option). *** 215,224 **** directories in the GDB distribution, if you only want to configure that subdirectory; but be sure to specify a path to it. ! For example, with version 4.18, type the following to configure only the `bfd' subdirectory: ! cd gdb-4.18/bfd ../configure You can install `gdb' anywhere; it has no hardwired paths. However, --- 218,227 ---- directories in the GDB distribution, if you only want to configure that subdirectory; but be sure to specify a path to it. ! For example, with version 5.0, type the following to configure only the `bfd' subdirectory: ! cd gdb-5.0/bfd ../configure You can install `gdb' anywhere; it has no hardwired paths. However, *************** directory. If the path to `configure' w *** 247,259 **** argument to `--srcdir', you can leave out the `--srcdir' option; it will be assumed.) ! For example, with version 4.18, you can build GDB in a separate directory for a Sun 4 like this: ! cd gdb-4.18 mkdir ../gdb-sun4 cd ../gdb-sun4 ! ../gdb-4.18/configure sun4 make When `configure' builds a configuration using a remote source --- 250,262 ---- argument to `--srcdir', you can leave out the `--srcdir' option; it will be assumed.) ! For example, with version 5.0, you can build GDB in a separate directory for a Sun 4 like this: ! cd gdb-5.0 mkdir ../gdb-sun4 cd ../gdb-sun4 ! ../gdb-5.0/configure make When `configure' builds a configuration using a remote source *************** called `configure' (or one of its subdir *** 274,281 **** The `Makefile' that `configure' generates in each source directory also runs recursively. If you type `make' in a source directory such ! as `gdb-4.18' (or in a separate configured directory configured with ! `--srcdir=PATH/gdb-4.18'), you will build all the required libraries, and then build GDB. When you have multiple hosts or targets configured in separate --- 277,284 ---- The `Makefile' that `configure' generates in each source directory also runs recursively. If you type `make' in a source directory such ! as `gdb-5.0' (or in a separate configured directory configured with ! `--srcdir=PATH/gdb-5.0'), you will build all the required libraries, and then build GDB. When you have multiple hosts or targets configured in separate *************** you can use it to test your guesses on a *** 318,324 **** Invalid configuration `i786v': machine `i786v' not recognized `config.sub' is also distributed in the GDB source directory ! (`gdb-4.18', for version 4.18). `configure' options --- 321,327 ---- Invalid configuration `i786v': machine `i786v' not recognized `config.sub' is also distributed in the GDB source directory ! (`gdb-5.0', for version 5.0). `configure' options *************** prefer; but you may abbreviate option na *** 372,382 **** code which looks even vaguely suspicious. You should only using this feature if you're compiling with GNU CC. It passes the following flags: ! -Wall -Wpointer-arith - -Wstrict-prototypes - -Wmissing-prototypes - -Wmissing-declarations `--target=TARGET' Configure GDB for cross-debugging programs running on the specified --- 375,387 ---- code which looks even vaguely suspicious. You should only using this feature if you're compiling with GNU CC. It passes the following flags: ! -Wimplicit ! -Wreturn-type ! -Wcomment ! -Wtrigraphs ! -Wformat ! -Wparentheses -Wpointer-arith `--target=TARGET' Configure GDB for cross-debugging programs running on the specified *************** See the GDB manual (gdb/doc/gdb.texinfo) *** 410,441 **** Kernel debugging ================= ! I have't done this myself so I can't really offer any advice. ! Remote debugging over serial lines works fine, but the kernel debugging ! code in here has not been tested in years. Van Jacobson has better kernel debugging, but the UC lawyers won't let FSF have it. Remote debugging ================= ! The files m68k-stub.c, i386-stub.c, and sparc-stub.c are examples of ! remote stubs to be used with remote.c. They are designed to run ! standalone on an m68k, i386, or SPARC cpu and communicate properly with ! the remote.c stub over a serial line. ! The directory gdb/gdbserver/ contains `gdbserver', a program that allows remote debugging for Unix applications. gdbserver is only ! supported for some native configurations, including Sun 3, Sun 4, ! and Linux. ! There are a number of remote interfaces for talking to existing ROM monitors and other hardware: remote-adapt.c AMD 29000 "Adapt" remote-array.c Array Tech RAID controller remote-bug.c Motorola BUG monitor - remote-d10v.c GDB protocol, talking to a d10v chip remote-e7000.c Hitachi E7000 ICE remote-eb.c AMD 29000 "EBMON" remote-es.c Ericsson 1800 monitor --- 415,445 ---- Kernel debugging ================= ! I have't done this myself so I can't really offer any advice. ! Remote debugging over serial lines works fine, but the kernel ! debugging code in here has not been tested in years. Van Jacobson has better kernel debugging, but the UC lawyers won't let FSF have it. Remote debugging ================= ! The files m68k-stub.c, i386-stub.c, and sparc-stub.c are examples ! of remote stubs to be used with remote.c. They are designed to run ! standalone on an m68k, i386, or SPARC cpu and communicate properly ! with the remote.c stub over a serial line. ! The directory gdb/gdbserver/ contains `gdbserver', a program that allows remote debugging for Unix applications. gdbserver is only ! supported for some native configurations, including Sun 3, Sun 4, and ! Linux. ! There are a number of remote interfaces for talking to existing ROM monitors and other hardware: remote-adapt.c AMD 29000 "Adapt" remote-array.c Array Tech RAID controller remote-bug.c Motorola BUG monitor remote-e7000.c Hitachi E7000 ICE remote-eb.c AMD 29000 "EBMON" remote-es.c Ericsson 1800 monitor *************** monitors and other hardware: *** 454,487 **** remote-udi.c AMD 29000 using the AMD "Universal Debug Interface" remote-vx.c VxWorks realtime kernel ! Remote-vx.c and the vx-share subdirectory contain a remote interface for the ! VxWorks realtime kernel, which communicates over TCP using the Sun ! RPC library. This would be a useful starting point for other remote- ! via-ethernet back ends. ! ! Remote-udi.c and the 29k-share subdirectory contain a remote interface ! for AMD 29000 programs, which uses the AMD "Universal Debug Interface". ! This allows GDB to talk to software simulators, emulators, and/or bare ! hardware boards, via network or serial interfaces. Note that GDB only ! provides an interface that speaks UDI, not a complete solution. You ! will need something on the other end that also speaks UDI. Reporting Bugs =============== ! The correct address for reporting bugs found in gdb is ! "bug-gdb@gnu.org". Please email all bugs, and all requests for ! help with GDB, to that address. Please include the GDB version number ! (e.g., gdb-4.18), and how you configured it (e.g., "sun4" or "mach386 host, i586-intel-synopsys target"). Since GDB now supports so many ! different configurations, it is important that you be precise about this. ! If at all possible, you should include the actual banner that GDB prints ! when it starts up, or failing that, the actual configure command that ! you used when configuring GDB. ! ! For more information on how/whether to report bugs, see the GDB Bugs ! section of the GDB manual (gdb/doc/gdb.texinfo). Known bugs: --- 458,493 ---- remote-udi.c AMD 29000 using the AMD "Universal Debug Interface" remote-vx.c VxWorks realtime kernel ! Remote-vx.c and the vx-share subdirectory contain a remote ! interface for the VxWorks realtime kernel, which communicates over TCP ! using the Sun RPC library. This would be a useful starting point for ! other remote- via-ethernet back ends. ! ! Remote-udi.c and the 29k-share subdirectory contain a remote ! interface for AMD 29000 programs, which uses the AMD "Universal Debug ! Interface". This allows GDB to talk to software simulators, ! emulators, and/or bare hardware boards, via network or serial ! interfaces. Note that GDB only provides an interface that speaks UDI, ! not a complete solution. You will need something on the other end ! that also speaks UDI. Reporting Bugs =============== ! The correct address for reporting bugs found in gdb is ! "bug-gdb@gnu.org". Please email all bugs, and all requests for help ! with GDB, to that address. Please include the GDB version number ! (e.g., gdb-5.0), and how you configured it (e.g., "sun4" or "mach386 host, i586-intel-synopsys target"). Since GDB now supports so many ! different configurations, it is important that you be precise about ! this. If at all possible, you should include the actual banner that ! GDB prints when it starts up, or failing that, the actual configure ! command that you used when configuring GDB. ! ! For more information on how/whether to report bugs, see the GDB ! Bugs section of the GDB manual (gdb/doc/gdb.texinfo) or the ! gdb/CONTRIBUTE file. Known bugs: *************** Known bugs: *** 533,596 **** * Under Irix 6 you must build with GCC. The vendor compiler reports as errors certain assignments that GCC considers to be warnings. - - * Notes for BSD/386: - To compile gdb-4.18 on BSD/386, you must run the configure script and - its subscripts with bash. Here is an easy way to do this: - - bash -c 'CONFIG_SHELL=/bin/bash ./configure' - - (configure will report i386-unknown-bsd). Then, compile with the - standard "make" command. ! * See, also the file TODO for other minor problems. - GDB can produce warnings about symbols that it does not understand. By - default, these warnings are disabled. You can enable them by executing - `set complaint 10' (which you can put in your ~/.gdbinit if you like). - I recommend doing this if you are working on a compiler, assembler, - linker, or GDB, since it will point out problems that you may be able - to fix. Warnings produced during symbol reading indicate some mismatch - between the object file and GDB's symbol reading code. In many cases, - it's a mismatch between the specs for the object file format, and what - the compiler actually outputs or the debugger actually understands. ! X Windows versus GDB ! ===================== ! You should check out DDD, the Data Display Debugger. Here's the blurb ! from the DDD web site, http://www.cs.tu-bs.de/softech/ddd: ! The Data Display Debugger (DDD) is a popular graphical user ! interface for command-line debuggers such as GDB, DBX, JDB, WDB, ! XDB, the Perl debugger, and the Python debugger. Besides ``usual'' ! front-end features such as viewing source texts, DDD has become ! famous through its interactive graphical data display, where data ! structures are displayed as graphs. A simple mouse click ! dereferences pointers or views structure contents, updated each ! time the program stops. Using DDD, you can reason about your ! application by watching its data, not just by viewing it execute ! lines of source code. ! ! Emacs users will very likely enjoy the Grand Unified Debugger mode; ! try typing `M-x gdb RET'. ! ! Those interested in experimenting with a new kind of gdb-mode ! should load gdb/gdba.el into GNU Emacs 19.25 or later. Comments ! on this mode are also welcome. Writing Code for GDB ===================== ! There is a lot of information about writing code for GDB in the internals manual, distributed with GDB in gdb/doc/gdbint.texinfo. You can read it by hand, print it by using TeX and texinfo, or process it into an `info' file for use with Emacs' info mode or the standalone `info' program. ! If you are pondering writing anything but a short patch, especially take note of the information about copyrights in the node Submitting Patches. It can take quite a while to get all the paperwork done, so we encourage you to start that process as soon as you decide you are --- 539,583 ---- * Under Irix 6 you must build with GCC. The vendor compiler reports as errors certain assignments that GCC considers to be warnings. ! GDB can produce warnings about symbols that it does not understand. ! By default, these warnings are disabled. You can enable them by ! executing `set complaint 10' (which you can put in your ~/.gdbinit if ! you like). I recommend doing this if you are working on a compiler, ! assembler, linker, or GDB, since it will point out problems that you ! may be able to fix. Warnings produced during symbol reading indicate ! some mismatch between the object file and GDB's symbol reading code. ! In many cases, it's a mismatch between the specs for the object file ! format, and what the compiler actually outputs or the debugger ! actually understands. + Graphical interface to GDB -- X Windows, MS Windows + ========================== ! Several graphical interfaces to GDB are available. You should ! check: ! ! http://sourceware.cygnus.com/gdb/#gui ! for an up-to-date list. ! Emacs users will very likely enjoy the Grand Unified Debugger mode; ! try typing `M-x gdb RET'. Those interested in experimenting with a ! new kind of gdb-mode should load gdb/gdba.el into GNU Emacs 19.25 or ! later. Comments on this mode are also welcome. Writing Code for GDB ===================== ! There is a lot of information about writing code for GDB in the internals manual, distributed with GDB in gdb/doc/gdbint.texinfo. You can read it by hand, print it by using TeX and texinfo, or process it into an `info' file for use with Emacs' info mode or the standalone `info' program. ! If you are pondering writing anything but a short patch, especially take note of the information about copyrights in the node Submitting Patches. It can take quite a while to get all the paperwork done, so we encourage you to start that process as soon as you decide you are *************** think you will be ready to submit the pa *** 601,626 **** GDB Testsuite ============= ! There is a DejaGNU based testsuite available for testing your newly ! built GDB, or for regression testing GDBs with local modifications. ! Running the testsuite requires the prior installation of DejaGNU, ! which is generally available via ftp; you'll need a pretty recent ! release. Once DejaGNU is installed, you can run the tests in one of ! two ways: ! (1) cd gdb-4.18/gdb (assuming you also unpacked gdb) make check or ! (2) cd gdb-4.18/gdb/testsuite make site.exp (builds the site specific file) runtest -tool gdb GDB=../gdb (or GDB= as appropriate) ! The second method gives you slightly more control in case of problems with ! building one or more test executables or if you are using the testsuite ! 'standalone', without it being part of the GDB source tree. See the DejaGNU documentation for further details. --- 588,620 ---- GDB Testsuite ============= ! Included with the GDB distribution is a DejaGNU based testsuite ! that can either be used to test your newly built GDB, or for ! regression testing a GDB with local modifications. ! ! Running the testsuite requires the prior installation of DejaGNU, ! which is generally available via ftp. The directory ! ftp://sourceware.cygnus.com/pub/dejagnu/ will contain a recent ! snapshot. Once DejaGNU is installed, you can run the tests in one of ! the following ways: ! (1) cd gdb-5.0 ! make check-gdb ! ! or ! (2) cd gdb-5.0/gdb make check or ! (3) cd gdb-5.0/gdb/testsuite make site.exp (builds the site specific file) runtest -tool gdb GDB=../gdb (or GDB= as appropriate) ! The last method gives you slightly more control in case of problems ! with building one or more test executables or if you are using the ! testsuite `standalone', without it being part of the GDB source tree. See the DejaGNU documentation for further details. >From ac131313@cygnus.com Thu May 11 03:32:00 2000 From: Andrew Cagney To: GDB Patches Subject: gdb-4.95.1.tar.bz2 created Date: Thu, 11 May 2000 03:32:00 -0000 Message-id: <391A8BFA.964B6620@cygnus.com> X-SW-Source: 2000-05/msg00171.html Content-length: 185 FYI, I've created another attempt at the final. At this stage I believe that the only problem is with ``credits'' in the gdb/doc directory. Andrew PS: Yes and threads on unixware. >From ac131313@cygnus.com Thu May 11 04:51:00 2000 From: Andrew Cagney To: GDB Patches Subject: [patch] gdbarch.sh, only print macro when defined Date: Thu, 11 May 2000 04:51:00 -0000 Message-id: <391A9E8D.704C23B5@cygnus.com> X-SW-Source: 2000-05/msg00172.html Content-length: 4463 FYI, I've committed the attached. It, firstly prints the value of GDB_MULTI_ARCH (more useful than you may expect) and secondly makes all the macro's printed in gdbarch_dump conditional on their definition. Andrew Thu May 11 21:33:59 2000 Andrew Cagney * gdbarch.sh (gdbarch_dump): Print the value of GDB_MULTI_ARCH. Always check that a macro is defined before printing it. * gdbarch.c: Re-generate. Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.20 diff -p -r1.20 gdbarch.sh *** gdbarch.sh 2000/05/10 17:38:16 1.20 --- gdbarch.sh 2000/05/11 11:47:17 *************** do *** 196,202 **** # An optional indicator for any predicte to wrap around the # print member code. - # # -> Wrap print up in ``#ifdef MACRO'' # exp -> Wrap print up in ``if (${print_p}) ... # ``'' -> No predicate --- 196,201 ---- *************** v:1:CALL_DUMMY_STACK_ADJUST_P:int:call_d *** 269,276 **** v:2:CALL_DUMMY_STACK_ADJUST:int:call_dummy_stack_adjust::::0::gdbarch->call_dummy_stack_adjust_p && gdbarch->call_dummy_stack_adjust == 0:0x%08lx::CALL_DUMMY_STACK_ADJUST_P f:2:FIX_CALL_DUMMY:void:fix_call_dummy:char *dummy, CORE_ADDR pc, CORE_ADDR fun, int nargs, struct value **args, struct type *type, int gcc_p:dummy, pc, fun, nargs, args, type, gcc_p::0:0 # ! v:2:BELIEVE_PCC_PROMOTION:int:believe_pcc_promotion::::0:::::# ! v:2:BELIEVE_PCC_PROMOTION_TYPE:int:believe_pcc_promotion_type::::0:::::# f:2:COERCE_FLOAT_TO_DOUBLE:int:coerce_float_to_double:struct type *formal, struct type *actual:formal, actual:::default_coerce_float_to_double:0 f:1:GET_SAVED_REGISTER:void:get_saved_register:char *raw_buffer, int *optimized, CORE_ADDR *addrp, struct frame_info *frame, int regnum, enum lval_type *lval:raw_buffer, optimized, addrp, frame, regnum, lval::generic_get_saved_register:0 # --- 268,275 ---- v:2:CALL_DUMMY_STACK_ADJUST:int:call_dummy_stack_adjust::::0::gdbarch->call_dummy_stack_adjust_p && gdbarch->call_dummy_stack_adjust == 0:0x%08lx::CALL_DUMMY_STACK_ADJUST_P f:2:FIX_CALL_DUMMY:void:fix_call_dummy:char *dummy, CORE_ADDR pc, CORE_ADDR fun, int nargs, struct value **args, struct type *type, int gcc_p:dummy, pc, fun, nargs, args, type, gcc_p::0:0 # ! v:2:BELIEVE_PCC_PROMOTION:int:believe_pcc_promotion::::0::::: ! v:2:BELIEVE_PCC_PROMOTION_TYPE:int:believe_pcc_promotion_type::::0::::: f:2:COERCE_FLOAT_TO_DOUBLE:int:coerce_float_to_double:struct type *formal, struct type *actual:formal, actual:::default_coerce_float_to_double:0 f:1:GET_SAVED_REGISTER:void:get_saved_register:char *raw_buffer, int *optimized, CORE_ADDR *addrp, struct frame_info *frame, int regnum, enum lval_type *lval:raw_buffer, optimized, addrp, frame, regnum, lval::generic_get_saved_register:0 # *************** gdbarch_dump (void) *** 1126,1131 **** --- 1125,1131 ---- EOF function_list | while do_read # eval read $read do + echo "#ifdef ${macro}" if class_is_function_p then echo " fprintf_unfiltered (gdb_stdlog," *************** do *** 1133,1147 **** echo " (long) current_gdbarch->${function}" echo " /*${macro} ()*/);" else ! if [ "${print_p}" = "#" ] then - echo "#ifdef ${macro}" - echo " fprintf_unfiltered (gdb_stdlog," - echo " \"gdbarch_update: ${macro} = ${fmt}\\n\"," - echo " ${print});" - echo "#endif" - elif [ "${print_p}" ] - then echo " if (${print_p})" echo " fprintf_unfiltered (gdb_stdlog," echo " \"gdbarch_update: ${macro} = ${fmt}\\n\"," --- 1133,1140 ---- echo " (long) current_gdbarch->${function}" echo " /*${macro} ()*/);" else ! if [ "${print_p}" ] then echo " if (${print_p})" echo " fprintf_unfiltered (gdb_stdlog," echo " \"gdbarch_update: ${macro} = ${fmt}\\n\"," *************** do *** 1152,1159 **** echo " ${print});" fi fi done ! echo "}" # GET/SET --- 1145,1158 ---- echo " ${print});" fi fi + echo "#endif" done ! cat <From ac131313@cygnus.com Thu May 11 05:04:00 2000 From: Andrew Cagney To: GDB Patches Subject: [rfc] Check that GCC accepts the given -W option Date: Thu, 11 May 2000 05:04:00 -0000 Message-id: <391AA18B.A4D970A@cygnus.com> X-SW-Source: 2000-05/msg00173.html Content-length: 1059 Hello, The attatched tweeks the configury so that it checks that a -W option is valid before trying to use it. Look ok? Andrew Thu May 11 21:52:55 2000 Andrew Cagney * configure.in (WERROR_CFLAGS): Check that GCC accepts a -W option before using it. Index: configure.in =================================================================== RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.21 diff -p -r1.21 configure.in *** configure.in 2000/04/14 10:13:50 1.21 --- configure.in 2000/05/11 11:54:05 *************** then *** 509,515 **** for w in ${build_warnings}; do case $w in -Werr*) WERROR_CFLAGS=-Werror ;; ! *) WARN_CFLAGS="${WARN_CFLAGS} $w" esac done fi --- 509,520 ---- for w in ${build_warnings}; do case $w in -Werr*) WERROR_CFLAGS=-Werror ;; ! *) # Check that GCC accepts it ! if $CC $w 2>&1 | grep 'unrecognized option' > /dev/null ; then ! : ! else ! WARN_CFLAGS="${WARN_CFLAGS} $w" ! fi esac done fi >From kettenis@wins.uva.nl Thu May 11 06:12:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb-4.95.1.tar.bz2 created Date: Thu, 11 May 2000 06:12:00 -0000 Message-id: <200005111312.PAA03572@landau.wins.uva.nl> References: <391A8BFA.964B6620@cygnus.com> X-SW-Source: 2000-05/msg00174.html Content-length: 902 Date: Thu, 11 May 2000 20:31:22 +1000 From: Andrew Cagney FYI, I've created another attempt at the final. At this stage I believe that the only problem is with ``credits'' in the gdb/doc directory. Assuming these pre-releases are targeted at a somewhat larger audience, it looks like we're somehow failing to reach this larger audience. I have seen no reaction related to the 4.95.0 tarball. Of course this could mean that it really has no problems, but I sincerely doubt that. Perhaps we could send a notice to a somewhat more public forum? The gnu.utils.bug newsgroup for example. Or perhaps HJ Lu could send a message to the people he used to send announcements of his "GDB for Linux"? Otherwise, we should probably be prepared to release GDB 5.1 (or perhaps 5.0.1) shortly after GDB 5.0 to fix some of the more acute bugs and building problems. Mark >From eliz@delorie.com Thu May 11 06:22:00 2000 From: Eli Zaretskii To: fnasser@cygnus.com Cc: mdejong@cygnus.com, dj@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 06:22:00 -0000 Message-id: <200005111321.JAA13143@indy.delorie.com> References: <3919C9EA.95DEC4A5@cygnus.com> X-SW-Source: 2000-05/msg00175.html Content-length: 371 > Date: Wed, 10 May 2000 16:43:22 -0400 > From: Fernando Nasser > > Gdb will silently exit on program exit, with the same return code > as the inferior ended. It might be a good idea to give users control on this particular aspect. I can imagine situations where a user would want gdb to not exit if, e.g., the program returned a non-zero status. >From fnasser@cygnus.com Thu May 11 06:47:00 2000 From: Fernando Nasser To: Eli Zaretskii Cc: mdejong@cygnus.com, dj@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 06:47:00 -0000 Message-id: <391AB98E.D80A537@cygnus.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> X-SW-Source: 2000-05/msg00176.html Content-length: 865 Eli Zaretskii wrote: > > > Date: Wed, 10 May 2000 16:43:22 -0400 > > From: Fernando Nasser > > > > Gdb will silently exit on program exit, with the same return code > > as the inferior ended. > > It might be a good idea to give users control on this particular > aspect. I can imagine situations where a user would want gdb to not > exit if, e.g., the program returned a non-zero status. Unfortunately it will be too late. When the program exits most UNIXes will get rid of the process data. But gdb will still read the .gdbinit file and, if you put a "b _exit" in there gdb will fire up as you want. Is that acceptable? -- Fernando Nasser Cygnus Solutions (a Red Hat company) E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From hjl@lucon.org Thu May 11 07:42:00 2000 From: "H . J . Lu" To: Mark Kettenis Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: gdb-4.95.1.tar.bz2 created Date: Thu, 11 May 2000 07:42:00 -0000 Message-id: <20000511074222.A25639@lucon.org> References: <391A8BFA.964B6620@cygnus.com> <200005111312.PAA03572@landau.wins.uva.nl> X-SW-Source: 2000-05/msg00177.html Content-length: 640 On Thu, May 11, 2000 at 03:12:07PM +0200, Mark Kettenis wrote: > > Perhaps we could send a notice to a somewhat more public forum? The > gnu.utils.bug newsgroup for example. Or perhaps HJ Lu could send a > message to the people he used to send announcements of his "GDB for > Linux"? I haven't looked at the gdb snapshots for a while. I hope it is better than the last time when I looked at. I am afraid I don't have much time for gdb for the time being. BTW, I assume you are aware that there is a gdb patch to support loading normal .a and .o files like .so files. It is needed for debugging the object loader in XFree86 4.0. H.J. >From tromey@cygnus.com Thu May 11 08:00:00 2000 From: Tom Tromey To: gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 08:00:00 -0000 Message-id: <87r9b9m9a9.fsf@cygnus.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> X-SW-Source: 2000-05/msg00178.html Content-length: 487 >>>>> "Fernando" == Fernando Nasser writes: Fernando> But gdb will still read the .gdbinit file and, if you put a Fernando> "b _exit" in there gdb will fire up as you want. Fernando> Is that acceptable? It seems like it wouldn't be too much work to add a `--interactive' option which will do all the setup but also ensure that you get a command prompt. Having an invisible mode is definitely nice. But sometimes pre-editing .gdbinit is a PITA. Tom >From fnasser@cygnus.com Thu May 11 08:32:00 2000 From: Fernando Nasser To: tromey@cygnus.com Cc: gdb-patches@sourceware.cygnus.com, Elena Zannoni Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 08:32:00 -0000 Message-id: <391AD28F.8C4E928F@cygnus.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> <87r9b9m9a9.fsf@cygnus.com> X-SW-Source: 2000-05/msg00179.html Content-length: 1215 Tom Tromey wrote: > > >>>>> "Fernando" == Fernando Nasser writes: > > Fernando> But gdb will still read the .gdbinit file and, if you put a > Fernando> "b _exit" in there gdb will fire up as you want. > > Fernando> Is that acceptable? > > It seems like it wouldn't be too much work to add a `--interactive' > option which will do all the setup but also ensure that you get a > command prompt. Having an invisible mode is definitely nice. But > sometimes pre-editing .gdbinit is a PITA. > --interactive sounds that -run would only set the arguments and give you the prompt (would not be a -run, but a -setargs). Is that what you mean? BTW, I just realized that we will have to run the target before printing the initial messages and the first prompt, and if the program exits without receiving a signal or a breakpoint, not to print them at all. On the other hand, if some event happens, we must enter the command loop. This may be tricky. Elena, what do you think? -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From kettenis@wins.uva.nl Thu May 11 08:43:00 2000 From: Mark Kettenis To: hjl@lucon.org Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: gdb-4.95.1.tar.bz2 created Date: Thu, 11 May 2000 08:43:00 -0000 Message-id: <200005111543.RAA03665@landau.wins.uva.nl> References: <391A8BFA.964B6620@cygnus.com> <200005111312.PAA03572@landau.wins.uva.nl> <20000511074222.A25639@lucon.org> X-SW-Source: 2000-05/msg00180.html Content-length: 2062 Date: Thu, 11 May 2000 07:42:22 -0700 From: "H . J . Lu" On Thu, May 11, 2000 at 03:12:07PM +0200, Mark Kettenis wrote: > > Perhaps we could send a notice to a somewhat more public forum? The > gnu.utils.bug newsgroup for example. Or perhaps HJ Lu could send a > message to the people he used to send announcements of his "GDB for > Linux"? I haven't looked at the gdb snapshots for a while. I hope it is better than the last time when I looked at. I am afraid I don't have much time for gdb for the time being. I'm not sure when was the last time that you looked at it. Probably a few critical bugs have been fixed since then. Some of the less critical bugs and more invasive changes have been put off till 5.1 (but most of these are already present on the main branch). I'm mostly happy with the current state, but then I'm mostly using GDB to debug GDB itself (on Linux and the Hurd) or debugging the Hurd. That's why I think it would be useful to get more people involved in testing GDB. But I'm not asking you to do that, at least not you alone. BTW, I assume you are aware that there is a gdb patch to support loading normal .a and .o files like .so files. It is needed for debugging the object loader in XFree86 4.0. No I'm not. This probably illustrates the problem I'm talking about. Many people in the Linux community think that *the* GDB for Linux is the one you maintain(ed). They send their bug reports and patches to you, not to one of the gdb mailing lists. Therefore I think it would be a good idea if we could send these people a message stating the state of affairs (opened up GDB develpment, live CVS repository, snapshot, soon to be released GDB 5.0) and encourage them to test the pre-realeses and send comments and patches to the GDB mailing lists. It would also be a great help if you could forward GDB-related mail you receive, to the GDB mailing lists. Concerning the XFree86 loader support: Where can we find the patches, and how can we find the author's? Mark >From tromey@cygnus.com Thu May 11 08:54:00 2000 From: Tom Tromey To: Fernando Nasser Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com, Elena Zannoni Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 08:54:00 -0000 Message-id: <200005111554.IAA17794@ferrule.cygnus.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> <87r9b9m9a9.fsf@cygnus.com> <391AD28F.8C4E928F@cygnus.com> X-SW-Source: 2000-05/msg00181.html Content-length: 283 Fernando> --interactive sounds that -run would only set the arguments Fernando> and give you the prompt (would not be a -run, but a Fernando> -setargs). Fernando> Is that what you mean? Yes. But it would also have to do the I/O redirection stuff and exit stats preservation. Tom >From hjl@lucon.org Thu May 11 09:12:00 2000 From: "H . J . Lu" To: Mark Kettenis Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: gdb-4.95.1.tar.bz2 created Date: Thu, 11 May 2000 09:12:00 -0000 Message-id: <20000511091218.A25932@lucon.org> References: <391A8BFA.964B6620@cygnus.com> <200005111312.PAA03572@landau.wins.uva.nl> <20000511074222.A25639@lucon.org> <200005111543.RAA03665@landau.wins.uva.nl> X-SW-Source: 2000-05/msg00182.html Content-length: 1954 On Thu, May 11, 2000 at 05:43:23PM +0200, Mark Kettenis wrote: > > I haven't looked at the gdb snapshots for a while. I hope it is > better than the last time when I looked at. I am afraid I don't have > much time for gdb for the time being. > > I'm not sure when was the last time that you looked at it. Probably a March 7 was my last gdb build. > few critical bugs have been fixed since then. Some of the less > critical bugs and more invasive changes have been put off till 5.1 > (but most of these are already present on the main branch). I'm > mostly happy with the current state, but then I'm mostly using GDB to > debug GDB itself (on Linux and the Hurd) or debugging the Hurd. > That's why I think it would be useful to get more people involved in > testing GDB. But I'm not asking you to do that, at least not you alone. > > BTW, I assume you are aware that there is a gdb patch to support > loading normal .a and .o files like .so files. It is needed for > debugging the object loader in XFree86 4.0. > > No I'm not. This probably illustrates the problem I'm talking about. > Many people in the Linux community think that *the* GDB for Linux is > the one you maintain(ed). They send their bug reports and patches to > you, not to one of the gdb mailing lists. Therefore I think it would > be a good idea if we could send these people a message stating the > state of affairs (opened up GDB develpment, live CVS repository, > snapshot, soon to be released GDB 5.0) and encourage them to test the > pre-realeses and send comments and patches to the GDB mailing lists. > It would also be a great help if you could forward GDB-related mail > you receive, to the GDB mailing lists. I knew about the patch because I am on the XFree86 developer mailing list. > > Concerning the XFree86 loader support: Where can we find the patches, > and how can we find the author's? http://www.dawa.demon.co.uk/xfree-gdb/ H.J. >From eliz@delorie.com Thu May 11 12:55:00 2000 From: Eli Zaretskii To: fnasser@cygnus.com Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com, ezannoni@cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 12:55:00 -0000 Message-id: <200005111955.PAA13556@indy.delorie.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> <87r9b9m9a9.fsf@cygnus.com> <391AD28F.8C4E928F@cygnus.com> X-SW-Source: 2000-05/msg00184.html Content-length: 638 > Date: Thu, 11 May 2000 11:32:31 -0400 > From: Fernando Nasser > > BTW, I just realized that we will have to run the target before printing > the initial messages and the first prompt, and if the program exits > without receiving a signal or a breakpoint, not to print them at all. > On the other hand, if some event happens, we must enter the command loop. > > This may be tricky. Elena, what do you think? Disabling the initial messages means --run will imply --quiet. Entering the command loop does not necessarily mean that the initial messages need to be printed at that time. Does this solve the problem? >From eliz@delorie.com Thu May 11 12:55:00 2000 From: Eli Zaretskii To: fnasser@cygnus.com Cc: mdejong@cygnus.com, dj@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 12:55:00 -0000 Message-id: <200005111955.PAA13553@indy.delorie.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> X-SW-Source: 2000-05/msg00183.html Content-length: 244 > Date: Thu, 11 May 2000 13:45:50 +0000 > From: Fernando Nasser > > But gdb will still read the .gdbinit file and, if you put a "b _exit" in > there gdb will fire up as you want. > > Is that acceptable? Yes, I think so. >From eliz@delorie.com Thu May 11 12:58:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [patch/5] README Date: Thu, 11 May 2000 12:58:00 -0000 Message-id: <200005111958.PAA13575@indy.delorie.com> References: <391A66C3.475F9B2D@cygnus.com> X-SW-Source: 2000-05/msg00185.html Content-length: 543 > Date: Thu, 11 May 2000 17:52:35 +1000 > From: Andrew Cagney > > I've committed the attached. It updates the file gdb/README. [snip] > *** 410,441 **** > Kernel debugging > ================= > > ! I have't done this myself so I can't really offer any advice. > ! Remote debugging over serial lines works fine, but the kernel debugging > ! code in here has not been tested in years. Van Jacobson has > better kernel debugging, but the UC lawyers won't let FSF have it. There's a typo in this hunk: "have't". >From mdejong@cygnus.com Thu May 11 13:18:00 2000 From: Mo DeJong To: gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 13:18:00 -0000 Message-id: References: <87r9b9m9a9.fsf@cygnus.com> X-SW-Source: 2000-05/msg00186.html Content-length: 698 On 11 May 2000, Tom Tromey wrote: > >>>>> "Fernando" == Fernando Nasser writes: > > Fernando> But gdb will still read the .gdbinit file and, if you put a > Fernando> "b _exit" in there gdb will fire up as you want. > > Fernando> Is that acceptable? > > It seems like it wouldn't be too much work to add a `--interactive' > option which will do all the setup but also ensure that you get a > command prompt. Having an invisible mode is definitely nice. But > sometimes pre-editing .gdbinit is a PITA. > > Tom How about --run-noexit, I am not sure that --interactive really makes it clear that the option is linked to the use of the --run option. Mo DeJong Red Hat Inc. >From fnasser@cygnus.com Thu May 11 13:26:00 2000 From: Fernando Nasser To: Mo DeJong Cc: gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 13:26:00 -0000 Message-id: <391B1780.23185181@cygnus.com> References: X-SW-Source: 2000-05/msg00187.html Content-length: 1252 Mo DeJong wrote: > > On 11 May 2000, Tom Tromey wrote: > > > >>>>> "Fernando" == Fernando Nasser writes: > > > > Fernando> But gdb will still read the .gdbinit file and, if you put a > > Fernando> "b _exit" in there gdb will fire up as you want. > > > > Fernando> Is that acceptable? > > > > It seems like it wouldn't be too much work to add a `--interactive' > > option which will do all the setup but also ensure that you get a > > command prompt. Having an invisible mode is definitely nice. But > > sometimes pre-editing .gdbinit is a PITA. > > > > Tom > > How about --run-noexit, I am not sure that --interactive really > makes it clear that the option is linked to the use of the --run > option. > I guess he really meant "interactive". Not exiting will do no good on native configurations because the inferior process is gone. What Tom wants is a way to "set args" from the command line. This seems more like a convenience though. The xdb style --run goes a little beyond what we currently offer. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From fnasser@cygnus.com Thu May 11 13:29:00 2000 From: Fernando Nasser To: Eli Zaretskii Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com, ezannoni@cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 13:29:00 -0000 Message-id: <391B1801.B2EA8531@cygnus.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> <87r9b9m9a9.fsf@cygnus.com> <391AD28F.8C4E928F@cygnus.com> <200005111955.PAA13556@indy.delorie.com> X-SW-Source: 2000-05/msg00188.html Content-length: 1078 Eli Zaretskii wrote: > > > Date: Thu, 11 May 2000 11:32:31 -0400 > > From: Fernando Nasser > > > > BTW, I just realized that we will have to run the target before printing > > the initial messages and the first prompt, and if the program exits > > without receiving a signal or a breakpoint, not to print them at all. > > On the other hand, if some event happens, we must enter the command loop. > > > > This may be tricky. Elena, what do you think? > > Disabling the initial messages means --run will imply --quiet. Good catch. Yes, we could do that. But if we ever get interactive we may want to be non-quiet again. > Entering the command loop does not necessarily mean that the initial > messages need to be printed at that time. > > Does this solve the problem? I am concerned with the prompt (actually, the read from stdin). -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From tromey@cygnus.com Thu May 11 15:30:00 2000 From: Tom Tromey To: gdb-patches@sourceware.cygnus.com Subject: Re: GDB needs a --cmdline option Date: Thu, 11 May 2000 15:30:00 -0000 Message-id: <87g0ron2qc.fsf@cygnus.com> References: <391B1780.23185181@cygnus.com> X-SW-Source: 2000-05/msg00189.html Content-length: 485 >>>>> "Fernando" == Fernando Nasser writes: Fernando> What Tom wants is a way to "set args" from the command line. No, I think it's more than that. It lets me insert a `gdb' call directly into a pipeline like `--run'. This mode would still handle stdin/out/err redirection issues like --run. It would just let me debug directly instead of pre-editing. Fernando> This seems more like a convenience though. Sometimes convenience is important. Tom >From ac131313@cygnus.com Thu May 11 16:42:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb-4.95.1.tar.bz2 created Date: Thu, 11 May 2000 16:42:00 -0000 Message-id: <391B4518.C52E83BA@cygnus.com> References: <391A8BFA.964B6620@cygnus.com> <200005111312.PAA03572@landau.wins.uva.nl> X-SW-Source: 2000-05/msg00190.html Content-length: 1102 Mark Kettenis wrote: > > Date: Thu, 11 May 2000 20:31:22 +1000 > From: Andrew Cagney > > FYI, > > I've created another attempt at the final. At this stage I believe that > the only problem is with ``credits'' in the gdb/doc directory. > > Assuming these pre-releases are targeted at a somewhat larger > audience, it looks like we're somehow failing to reach this larger > audience. I have seen no reaction related to the 4.95.0 tarball. Of > course this could mean that it really has no problems, but I sincerely > doubt that. FYI, they are targeted at people that want to check that I've bundled up the final distribution correctly. At this point the audience is likely to be very small - Eli for DOS, CGF for cygwin and me for random platform of the day. If others come along and down load it then thats a bonus. For wider distribution, I'd rather push out 5.0 and use that as the leverage (groan) for promoting CVS and 5.1/5.0.1. Most people interested in GDB just check out a copy from CVS. Well, at least that is the theory, :-) enjoy, Andrew >From ac131313@cygnus.com Thu May 11 22:48:00 2000 From: Andrew Cagney To: GDB Patches Subject: Re: [rfc] Check that GCC accepts the given -W option Date: Thu, 11 May 2000 22:48:00 -0000 Message-id: <391B9AEB.3D6B6DE7@cygnus.com> References: <391AA18B.A4D970A@cygnus.com> X-SW-Source: 2000-05/msg00191.html Content-length: 528 Andrew Cagney wrote: > > Hello, > > The attatched tweeks the configury so that it checks that a -W option is > valid before trying to use it. > Look ok? > > Andrew > > ------------------------------------------------------------------------ > Thu May 11 21:52:55 2000 Andrew Cagney > > * configure.in (WERROR_CFLAGS): Check that GCC accepts a -W option > before using it. FYI, I've checked in a cleanup of this patch - it also reports the results of the probe. Andrew >From msnyder@cygnus.com Thu May 11 22:58:00 2000 From: Michael Snyder To: cgf@cygnus.com, eliz@gnu.org, gdb-patches@sourceware.cygnus.com, kettenis@gnu.org Cc: jtc@redback.com, nsd@cygnus.com Subject: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Thu, 11 May 2000 22:58:00 -0000 Message-id: <200005120557.WAA05792@cleaver.cygnus.com> X-SW-Source: 2000-05/msg00192.html Content-length: 4311 Hello, >From the evidence, it appears that i386-gcc passes floats on the stack after promoting them to doubles. At least I've verified this on Linux, Solaris and Unixware. This patch fixes five testsuite failures by making GDB pass floats as doubles when it calls a target function. I'd appreciate verification / approval from the maintainers of other x86 platforms such as Hurd, DJGPP, Cygwin, BSD etc. If this change isn't good for some of you, we can move the #define PUSH_ARGUMENTS into the individual tm.h files. 2000-05-11 Michael Snyder * i386-tdep.c (i386_push_arguments): New function; differs from default_push_arguments in that it promotes floats to doubles. * valops.c (value_push): Export. * value.h (value_push): Declare. * config/i386/tm-i386.h (PUSH_ARGUMENTS): Define. Index: value.h =================================================================== RCS file: /cvs/src/src/gdb/value.h,v retrieving revision 1.4 diff -p -r1.4 value.h *** value.h 2000/04/27 15:33:01 1.4 --- value.h 2000/05/12 05:47:05 *************** extern int baseclass_offset PARAMS ((str *** 548,553 **** --- 548,555 ---- /* From valops.c */ + extern CORE_ADDR value_push PARAMS ((CORE_ADDR, value_ptr)); + extern value_ptr varying_to_slice PARAMS ((value_ptr)); extern value_ptr value_slice PARAMS ((value_ptr, int, int)); Index: valops.c =================================================================== RCS file: /cvs/src/src/gdb/valops.c,v retrieving revision 1.12 diff -p -r1.12 valops.c *** valops.c 2000/04/22 06:44:39 1.12 --- valops.c 2000/05/12 05:47:06 *************** static CORE_ADDR find_function_addr PARA *** 47,54 **** static value_ptr value_arg_coerce PARAMS ((value_ptr, struct type *, int)); - static CORE_ADDR value_push PARAMS ((CORE_ADDR, value_ptr)); - static value_ptr search_struct_field PARAMS ((char *, value_ptr, int, struct type *, int)); --- 47,52 ---- *************** push_bytes (sp, buffer, len) *** 1072,1078 **** /* Push onto the stack the specified value VALUE. Pad it correctly for it to be an argument to a function. */ ! static CORE_ADDR value_push (sp, arg) register CORE_ADDR sp; value_ptr arg; --- 1070,1076 ---- /* Push onto the stack the specified value VALUE. Pad it correctly for it to be an argument to a function. */ ! CORE_ADDR value_push (sp, arg) register CORE_ADDR sp; value_ptr arg; Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.9 diff -p -r1.9 i386-tdep.c *** i386-tdep.c 2000/03/26 21:21:50 1.9 --- i386-tdep.c 2000/05/12 05:47:06 *************** i386_push_dummy_frame () *** 636,641 **** --- 636,668 ---- write_register (SP_REGNUM, sp); } + /* PUSH_ARGUMENTS for the 386 differs from the default in that + floats are promoted to doubles. MVS 5/11/2000 */ + + CORE_ADDR + i386_push_arguments (nargs, args, sp, struct_return, struct_addr) + int nargs; + value_ptr *args; + CORE_ADDR sp; + int struct_return; + CORE_ADDR struct_addr; + { + /* ASSERT ( !struct_return); */ + int i; + + for (i = nargs - 1; i >= 0; i--) + { + value_ptr copyarg = args[i]; + struct type *argtype = check_typedef (VALUE_TYPE (copyarg)); + + if (TYPE_CODE (argtype) == TYPE_CODE_FLT && TYPE_LENGTH (argtype) == 4) + copyarg = value_cast (builtin_type_double, copyarg); + + sp = value_push (sp, copyarg); + } + return sp; + } + void i386_pop_frame () { Index: config/i386/tm-i386.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v retrieving revision 1.5 diff -p -r1.5 tm-i386.h *** tm-i386.h 2000/04/14 19:13:07 1.5 --- tm-i386.h 2000/05/12 05:47:06 *************** extern void print_387_status_word PARAMS *** 428,431 **** --- 428,438 ---- #define SP_ARG0 (1 * 4) + /* Don't use the default push_arguments. + i386 requires floats to be passed as longs. */ + + struct value; + #define PUSH_ARGUMENTS i386_push_arguments + extern CORE_ADDR i386_push_arguments PARAMS ((int, struct value **, + CORE_ADDR, int, CORE_ADDR)); #endif /* ifndef TM_I386_H */ >From ac131313@cygnus.com Fri May 12 02:19:00 2000 From: Andrew Cagney To: GDB Patches Subject: [patch] One 32 bit ABI mips bug on 64 bit ISA Date: Fri, 12 May 2000 02:19:00 -0000 Message-id: <391BCC49.E08EC612@cygnus.com> X-SW-Source: 2000-05/msg00193.html Content-length: 3405 FYI, The attached fixes a bug with 32 bit ABIs on 64 bit MIPS ISAs. The generic version of fetch registers was reading in too many bytes. Andrew Fri May 12 19:13:15 2000 Andrew Cagney * mips-tdep.c (mips_get_saved_register): New function. Handle case of 32 ABI saving 32 bit registers on stack when target has 64 bit ISA. (mips_gdbarch_init): Update. Index: mips-tdep.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/mips-tdep.c,v retrieving revision 1.216 diff -p -r1.216 mips-tdep.c *** mips-tdep.c 2000/05/12 06:05:54 1.216 --- mips-tdep.c 2000/05/12 09:15:31 *************** mips_coerce_float_to_double (struct type *** 3984,3989 **** --- 3984,4055 ---- return current_language->la_language == language_c; } + /* When debugging a 64 MIPS target running a 32 bit ABI, the size of + the register stored on the stack (32) is different to its real raw + size (64). The below ensures that registers are fetched from the + stack using their ABI size and then stored into the RAW_BUFFER + using their raw size. + + The alternative to adding this function would be to add an ABI + macro - REGISTER_STACK_SIZE(). */ + + static void + mips_get_saved_register (raw_buffer, optimized, addrp, frame, regnum, lval) + char *raw_buffer; + int *optimized; + CORE_ADDR *addrp; + struct frame_info *frame; + int regnum; + enum lval_type *lval; + { + CORE_ADDR addr; + + if (!target_has_registers) + error ("No registers."); + + /* Normal systems don't optimize out things with register numbers. */ + if (optimized != NULL) + *optimized = 0; + addr = find_saved_register (frame, regnum); + if (addr != 0) + { + if (lval != NULL) + *lval = lval_memory; + if (regnum == SP_REGNUM) + { + if (raw_buffer != NULL) + { + /* Put it back in target format. */ + store_address (raw_buffer, REGISTER_RAW_SIZE (regnum), + (LONGEST) addr); + } + if (addrp != NULL) + *addrp = 0; + return; + } + if (raw_buffer != NULL) + { + LONGEST val; + if (regnum < 32) + /* Only MIPS_SAVED_REGSIZE bytes of GP registers are + saved. */ + val = read_memory_integer (addr, MIPS_SAVED_REGSIZE); + else + val = read_memory_integer (addr, REGISTER_RAW_SIZE (regnum)); + store_address (raw_buffer, REGISTER_RAW_SIZE (regnum), val); + } + } + else + { + if (lval != NULL) + *lval = lval_register; + addr = REGISTER_BYTE (regnum); + if (raw_buffer != NULL) + read_register_gen (regnum, raw_buffer); + } + if (addrp != NULL) + *addrp = addr; + } static gdbarch_init_ftype mips_gdbarch_init; static struct gdbarch * *************** mips_gdbarch_init (info, arches) *** 4276,4282 **** set_gdbarch_coerce_float_to_double (gdbarch, mips_coerce_float_to_double); set_gdbarch_frame_chain_valid (gdbarch, func_frame_chain_valid); ! set_gdbarch_get_saved_register (gdbarch, default_get_saved_register); if (gdbarch_debug) { --- 4342,4348 ---- set_gdbarch_coerce_float_to_double (gdbarch, mips_coerce_float_to_double); set_gdbarch_frame_chain_valid (gdbarch, func_frame_chain_valid); ! set_gdbarch_get_saved_register (gdbarch, mips_get_saved_register); if (gdbarch_debug) { >From ac131313@cygnus.com Fri May 12 03:15:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [patch/5] README Date: Fri, 12 May 2000 03:15:00 -0000 Message-id: <391BD95E.6DEDEE3@cygnus.com> References: <391A66C3.475F9B2D@cygnus.com> <200005111958.PAA13575@indy.delorie.com> X-SW-Source: 2000-05/msg00194.html Content-length: 1652 Eli Zaretskii wrote: > > > Date: Thu, 11 May 2000 17:52:35 +1000 > > From: Andrew Cagney > > > > I've committed the attached. It updates the file gdb/README. > [snip] > > *** 410,441 **** > > Kernel debugging > > ================= > > > > ! I have't done this myself so I can't really offer any advice. > > ! Remote debugging over serial lines works fine, but the kernel debugging > > ! code in here has not been tested in years. Van Jacobson has > > better kernel debugging, but the UC lawyers won't let FSF have it. > > There's a typo in this hunk: "have't". ``Fixed''. Thanks. Andrew Fri May 12 14:12:17 2000 Andrew Cagney * README: Update section on kernel debugging. Index: README =================================================================== RCS file: /cvs/src/src/gdb/README,v retrieving revision 1.1.1.2.2.3 diff -p -r1.1.1.2.2.3 README *** README 2000/05/11 07:55:16 1.1.1.2.2.3 --- README 2000/05/12 10:11:47 *************** See the GDB manual (gdb/doc/gdb.texinfo) *** 415,422 **** Kernel debugging ================= ! I have't done this myself so I can't really offer any advice. ! Remote debugging over serial lines works fine, but the kernel debugging code in here has not been tested in years. Van Jacobson has better kernel debugging, but the UC lawyers won't let FSF have it. --- 415,421 ---- Kernel debugging ================= ! Remote debugging over serial lines works fine, but the kernel debugging code in here has not been tested in years. Van Jacobson has better kernel debugging, but the UC lawyers won't let FSF have it. >From ac131313@cygnus.com Fri May 12 03:31:00 2000 From: Andrew Cagney To: Brian Youmans <3diff@gnu.org> Cc: fnasser@cygnus.com, dj@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: authorship Date: Fri, 12 May 2000 03:31:00 -0000 Message-id: <391BDCF6.229B86D8@cygnus.com> References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> <200005081637.MAA18610@envy.delorie.com> <3916F261.EB8FAD0C@cygnus.com> <200005081809.OAA20154@delysid.gnu.org> X-SW-Source: 2000-05/msg00195.html Content-length: 518 Brian Youmans wrote: > > RMS thinks "Richard Stallman, Roland Pesch, Stan Shebs, et al." is a > good idea. I still like "and others", but I'm willing to compromise. > If there are no objections, I will implement that here on our printed > manuals, asnd someone should implement it in gdb.texinfo. > > After that, I will go ahead and print the manual, and stop pestering > the list. > > Is there a present target for GDB 5 release? > > - Brian Youmans, FSF FYI, I've applied this change to gdb.texinfo. Andrew >From eliz@delorie.com Fri May 12 03:51:00 2000 From: Eli Zaretskii To: fnasser@cygnus.com Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com, ezannoni@cygnus.com Subject: Re: GDB needs a --cmdline option Date: Fri, 12 May 2000 03:51:00 -0000 Message-id: <200005121050.GAA14380@indy.delorie.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> <87r9b9m9a9.fsf@cygnus.com> <391AD28F.8C4E928F@cygnus.com> <200005111955.PAA13556@indy.delorie.com> <391B1801.B2EA8531@cygnus.com> X-SW-Source: 2000-05/msg00196.html Content-length: 386 > Date: Thu, 11 May 2000 16:28:49 -0400 > From: Fernando Nasser > > > Entering the command loop does not necessarily mean that the initial > > messages need to be printed at that time. > > > > Does this solve the problem? > > I am concerned with the prompt (actually, the read from stdin). Sorry, I'm probably missing something. What problems do you see here? >From eliz@delorie.com Fri May 12 03:52:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com Subject: Re: gdb-4.95.1.tar.bz2 created Date: Fri, 12 May 2000 03:52:00 -0000 Message-id: <200005121052.GAA14396@indy.delorie.com> References: <391A8BFA.964B6620@cygnus.com> <200005111312.PAA03572@landau.wins.uva.nl> <391B4518.C52E83BA@cygnus.com> X-SW-Source: 2000-05/msg00198.html Content-length: 1028 > Date: Fri, 12 May 2000 09:41:12 +1000 > From: Andrew Cagney > > FYI, they are targeted at people that want to check that I've bundled up > the final distribution correctly. At this point the audience is likely > to be very small - Eli for DOS, CGF for cygwin and me for random > platform of the day. I plan to ask people on the DJGPP developers' list to try the pretest, once I make sure it builds for me without problems. > Most people interested in GDB just check out a copy from CVS. > > Well, at least that is the theory, :-) IMHO, the official releases and semi-official pretests still have an important role: they force the developers to try to put out a stable distribution. In contrast, grave bugs that are found in the CVS tree can always be dismissed on the grounds that development sources are by definition unstable. Users who want reliable tools (as opposed to hackers who want to hack ;-) will not be happy with packages whose distribution is based solely on CVS. IMHO, of course. >From eliz@delorie.com Fri May 12 03:52:00 2000 From: Eli Zaretskii To: msnyder@cygnus.com Cc: cgf@cygnus.com, gdb-patches@sourceware.cygnus.com, kettenis@gnu.org, jtc@redback.com, nsd@cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 03:52:00 -0000 Message-id: <200005121051.GAA14389@indy.delorie.com> References: <200005120557.WAA05792@cleaver.cygnus.com> X-SW-Source: 2000-05/msg00197.html Content-length: 661 > From: Michael Snyder > Date: Thu, 11 May 2000 22:57:53 -0700 (PDT) > > From the evidence, it appears that i386-gcc passes floats on the > stack after promoting them to doubles. At least I've verified this > on Linux, Solaris and Unixware. This patch fixes five testsuite > failures by making GDB pass floats as doubles when it calls a > target function. I'd appreciate verification / approval from the > maintainers of other x86 platforms such as Hurd, DJGPP, Cygwin, > BSD etc. Could you please identify the tests in the test suite, or post a short test program and a GDB session script, that could be used to test this problem? >From ac131313@cygnus.com Fri May 12 04:10:00 2000 From: Andrew Cagney To: GDB Patches Subject: So, any objections to kicking 5.0 out? Date: Fri, 12 May 2000 04:10:00 -0000 Message-id: <391BE658.2F07E317@cygnus.com> X-SW-Source: 2000-05/msg00199.html Content-length: 70 According to my diary, 5.1 should start in a month or so ... Andrew >From ac131313@cygnus.com Fri May 12 04:10:00 2000 From: Andrew Cagney To: "Nick Duffek Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: thread.c: handle "q" during "info threads" Date: Fri, 12 May 2000 04:10:00 -0000 Message-id: <391BE689.49E892A8@cygnus.com> References: <200004121650.QAA13711@nog.bosbc.com> X-SW-Source: 2000-05/msg00200.html Content-length: 948 "Nick Duffek > > When debugging program with many threads, the "info threads" command may > generate multiple screenfuls of information interleaved with "---Type > to continue, or q to quit---" prompts. > > If "q" is typed in response to that prompt, one of two bad things happen: > > 1. If the prompt occurred between two wrapped lines describing the same > thread, GDB ignores the quit request. > > 2. Otherwise, GDB decides that the last thread displayed is the current > thread. > > Here are two patches to fix that problem. The first patch uses the new > catch_errors() interface I proposed in my earlier post entitled "RFA: > top.c: new catch_errors + cleanup interface". The second patch uses the > current interface. > > There are no regressions for either patch on sparc-sun-solaris2.6. > > Okay to commit one or the other? Nick, I'd apply the second of these two patches for the moment. Andrew >From 3diff@gnu.org Fri May 12 07:03:00 2000 From: Brian Youmans <3diff@gnu.org> To: gdb-patches@sourceware.cygnus.com Subject: another libc1 compiling error Date: Fri, 12 May 2000 07:03:00 -0000 Message-id: <200005121357.JAA04893@crapple-jacks.gnu.ai.mit.edu> X-SW-Source: 2000-05/msg00201.html Content-length: 1243 Once again attempting to compile the latest snapshot on delysid.gnu.org, it failed as follows: 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 os9kread.c 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 top.c 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 utils.c In file included from utils.c:31: /usr/include/term.h:44: conflicting types for `ttytype' /usr/include/curses.h:177: previous declaration of `ttytype' /usr/include/term.h:565: conflicting types for `tgetent' /usr/include/termcap.h:31: previous declaration of `tgetent' /usr/include/term.h:574: conflicting types for `tputs' /usr/include/termcap.h:39: previous declaration of `tputs' make[1]: *** [utils.o] Error 1 make[1]: Leaving directory `/gnu/fsf/fsf/3diff/gdb+dejagnu-20000511/gdb' make: *** [all-gdb] Error 2 Hope this is useful. - Brian Youmans, FSF office staff >From fnasser@cygnus.com Fri May 12 07:26:00 2000 From: Fernando Nasser To: Eli Zaretskii Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com, ezannoni@cygnus.com Subject: Re: GDB needs a --cmdline option Date: Fri, 12 May 2000 07:26:00 -0000 Message-id: <391C1435.32B01AC1@cygnus.com> References: <3919C9EA.95DEC4A5@cygnus.com> <200005111321.JAA13143@indy.delorie.com> <391AB98E.D80A537@cygnus.com> <87r9b9m9a9.fsf@cygnus.com> <391AD28F.8C4E928F@cygnus.com> <200005111955.PAA13556@indy.delorie.com> <391B1801.B2EA8531@cygnus.com> <200005121050.GAA14380@indy.delorie.com> X-SW-Source: 2000-05/msg00202.html Content-length: 863 Eli Zaretskii wrote: > > > Date: Thu, 11 May 2000 16:28:49 -0400 > > From: Fernando Nasser > > > > > Entering the command loop does not necessarily mean that the initial > > > messages need to be printed at that time. > > > > > > Does this solve the problem? > > > > I am concerned with the prompt (actually, the read from stdin). > > Sorry, I'm probably missing something. What problems do you see here? We don't want gdb to print a prompt and much less try to read from stdin unless some event happen and activate the debugger. It should not interfere and stop your script if the execution of the inferior goes smooth. -- Fernando Nasser Cygnus Solutions (a Red Hat company) E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From kettenis@wins.uva.nl Fri May 12 07:36:00 2000 From: Mark Kettenis To: 3diff@gnu.org Cc: gdb-patches@sourceware.cygnus.com Subject: Re: another libc1 compiling error Date: Fri, 12 May 2000 07:36:00 -0000 Message-id: <200005121436.QAA13337@landau.wins.uva.nl> References: <200005121357.JAA04893@crapple-jacks.gnu.ai.mit.edu> X-SW-Source: 2000-05/msg00203.html Content-length: 2297 Date: Fri, 12 May 2000 09:57:11 -0400 From: Brian Youmans <3diff@gnu.org> Once again attempting to compile the latest snapshot on delysid.gnu.org, it failed as follows: 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 os9kread.c 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 top.c 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 utils.c In file included from utils.c:31: /usr/include/term.h:44: conflicting types for `ttytype' /usr/include/curses.h:177: previous declaration of `ttytype' /usr/include/term.h:565: conflicting types for `tgetent' /usr/include/termcap.h:31: previous declaration of `tgetent' /usr/include/term.h:574: conflicting types for `tputs' /usr/include/termcap.h:39: previous declaration of `tputs' make[1]: *** [utils.o] Error 1 make[1]: Leaving directory `/gnu/fsf/fsf/3diff/gdb+dejagnu-20000511/gdb' make: *** [all-gdb] Error 2 Hmm. The GDB configure script fails to recognize the somewhat broken curses instalation on delysid. The problem is that delysid has both ncurses and the old BSD curses installed, where /usr/include/curses.h is the BSD header, and /usr/include/ncurses/curses.h is the ncurses header. In addition there is /usr/include/ncurses/term.h, but somehow the same file is also installed as /usr/include/term.h. So the compiler is using the ncurses together with the BSD , which obviously doesn't work. The solution is to make GDB use the headers in /usr/include/ncurses. Running configure with CPPFLAGS=-I/usr/include/ncurses should work: $ CPPFLAGS=-I/usr/include/ncurses ./configure ... Note that GDB is prefers -lncurses over -lcurses, so using the BSD header wouldn't work anyway. There isn't much we can do in GDB to detect this lossage. I suppose there aren't that many machines out there with that have both BSD curses and ncurses installed in /usr. Mark >From msnyder@cygnus.com Fri May 12 08:09:00 2000 From: Michael Snyder To: Eli Zaretskii Cc: cgf@cygnus.com, gdb-patches@sourceware.cygnus.com, kettenis@gnu.org, jtc@redback.com, nsd@cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 08:09:00 -0000 Message-id: <391C1E1C.2386@cygnus.com> References: <200005120557.WAA05792@cleaver.cygnus.com> <200005121051.GAA14389@indy.delorie.com> X-SW-Source: 2000-05/msg00204.html Content-length: 1198 Eli Zaretskii wrote: > > > From: Michael Snyder > > Date: Thu, 11 May 2000 22:57:53 -0700 (PDT) > > > > From the evidence, it appears that i386-gcc passes floats on the > > stack after promoting them to doubles. At least I've verified this > > on Linux, Solaris and Unixware. This patch fixes five testsuite > > failures by making GDB pass floats as doubles when it calls a > > target function. I'd appreciate verification / approval from the > > maintainers of other x86 platforms such as Hurd, DJGPP, Cygwin, > > BSD etc. > > Could you please identify the tests in the test suite, or post a short > test program and a GDB session script, that could be used to test this > problem? Sure. make check RUNTESTFLAGS=callfuncs.exp FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) FAIL: gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) The problem is that GDB passes the float values as floats, while the callee expects them to be doubles. >From msnyder@cygnus.com Fri May 12 08:13:00 2000 From: Michael Snyder To: Brian Youmans <3diff@gnu.org> Cc: gdb-patches@sourceware.cygnus.com Subject: Re: another libc1 compiling error Date: Fri, 12 May 2000 08:13:00 -0000 Message-id: <391C1EEB.17EC@cygnus.com> References: <200005121357.JAA04893@crapple-jacks.gnu.ai.mit.edu> X-SW-Source: 2000-05/msg00205.html Content-length: 1385 Brian Youmans wrote: > > Once again attempting to compile the latest > snapshot on delysid.gnu.org, it failed as follows: Brian, What kind of machine and OS is delysid? Thanks, Michael Snyder > > 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 os9kread.c > 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 top.c > 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 utils.c > In file included from utils.c:31: > /usr/include/term.h:44: conflicting types for `ttytype' > /usr/include/curses.h:177: previous declaration of `ttytype' > /usr/include/term.h:565: conflicting types for `tgetent' > /usr/include/termcap.h:31: previous declaration of `tgetent' > /usr/include/term.h:574: conflicting types for `tputs' > /usr/include/termcap.h:39: previous declaration of `tputs' > make[1]: *** [utils.o] Error 1 > make[1]: Leaving directory `/gnu/fsf/fsf/3diff/gdb+dejagnu-20000511/gdb' > make: *** [all-gdb] Error 2 > > Hope this is useful. > > - Brian Youmans, FSF office staff >From kettenis@wins.uva.nl Fri May 12 09:33:00 2000 From: Mark Kettenis To: msnyder@cygnus.com Cc: eliz@is.elta.co.il, cgf@cygnus.com, gdb-patches@sourceware.cygnus.com, jtc@redback.com, nsd@cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 09:33:00 -0000 Message-id: <200005121633.SAA17193@landau.wins.uva.nl> References: <200005120557.WAA05792@cleaver.cygnus.com> <200005121051.GAA14389@indy.delorie.com> <391C1E1C.2386@cygnus.com> X-SW-Source: 2000-05/msg00206.html Content-length: 1672 Date: Fri, 12 May 2000 08:07:08 -0700 From: Michael Snyder Eli Zaretskii wrote: > > > From: Michael Snyder > > Date: Thu, 11 May 2000 22:57:53 -0700 (PDT) > > > > From the evidence, it appears that i386-gcc passes floats on the > > stack after promoting them to doubles. At least I've verified this > > on Linux, Solaris and Unixware. This patch fixes five testsuite > > failures by making GDB pass floats as doubles when it calls a > > target function. I'd appreciate verification / approval from the > > maintainers of other x86 platforms such as Hurd, DJGPP, Cygwin, > > BSD etc. > > Could you please identify the tests in the test suite, or post a short > test program and a GDB session script, that could be used to test this > problem? Sure. make check RUNTESTFLAGS=callfuncs.exp FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) FAIL: gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) I don't see those failures on Linux. Calling functions that use the FPU doesn't work reliably on the Hurd right now. The problem is that GDB passes the float values as floats, while the callee expects them to be doubles. Are you sure? I already said that things appear to be working fine on Linux, and the System V ABI says that single-precision floating-point arguments occupy a single word on the stack. Mark >From msnyder@cygnus.com Fri May 12 10:29:00 2000 From: Michael Snyder To: Mark Kettenis Cc: eliz@is.elta.co.il, cgf@cygnus.com, gdb-patches@sourceware.cygnus.com, jtc@redback.com, nsd@cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 10:29:00 -0000 Message-id: <391C3ED8.894@cygnus.com> References: <200005120557.WAA05792@cleaver.cygnus.com> <200005121051.GAA14389@indy.delorie.com> <391C1E1C.2386@cygnus.com> <200005121633.SAA17193@landau.wins.uva.nl> X-SW-Source: 2000-05/msg00207.html Content-length: 863 Mark Kettenis wrote: > Sure. > make check RUNTESTFLAGS=callfuncs.exp > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) > FAIL: gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) > > I don't see those failures on Linux. Really??? I do! I wonder whether it's a Linux version diff, or a compiler diff. What versions are you using? Mine are: %] msnyder<12>% gcc -v Reading specs from /usr/progressive/bin/../lib/gcc-lib/i386-pc-linux-gnu/2.9-gnu pro-98r1/specs gcc version 2.9-gnupro-98r1 %] msnyder<14>% uname -a Linux happy.cygnus.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown >From jtc@redback.com Fri May 12 11:27:00 2000 From: jtc@redback.com (J.T. Conklin) To: msnyder@cygnus.com Cc: Eli Zaretskii , cgf@cygnus.com, gdb-patches@sourceware.cygnus.com, kettenis@gnu.org, nsd@cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 11:27:00 -0000 Message-id: <5mhfc3eiaf.fsf@jtc.redback.com> References: <200005120557.WAA05792@cleaver.cygnus.com> <200005121051.GAA14389@indy.delorie.com> <391C1E1C.2386@cygnus.com> X-SW-Source: 2000-05/msg00208.html Content-length: 852 >>>>> "Michael" == Michael Snyder writes: >> Could you please identify the tests in the test suite, or post a short >> test program and a GDB session script, that could be used to test this >> problem? Michael> make check RUNTESTFLAGS=callfuncs.exp Michael> FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) Michael> FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) Michael> FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) Michael> FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) Michael> FAIL: gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) These test pass without your patch on NetBSD/i386. I have not tried adding your patch to see if they continue to pass. Would you like me to do so? --jtc -- J.T. Conklin RedBack Networks >From kettenis@wins.uva.nl Fri May 12 11:40:00 2000 From: Mark Kettenis To: msnyder@cygnus.com Cc: eliz@is.elta.co.il, cgf@cygnus.com, gdb-patches@sourceware.cygnus.com, jtc@redback.com, nsd@cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 11:40:00 -0000 Message-id: <200005121839.e4CIdvw00368@delius.kettenis.local> References: <200005120557.WAA05792@cleaver.cygnus.com> <200005121051.GAA14389@indy.delorie.com> <391C1E1C.2386@cygnus.com> <200005121633.SAA17193@landau.wins.uva.nl> <391C3ED8.894@cygnus.com> X-SW-Source: 2000-05/msg00209.html Content-length: 2266 Date: Fri, 12 May 2000 10:26:48 -0700 From: Michael Snyder Mark Kettenis wrote: > Sure. > make check RUNTESTFLAGS=callfuncs.exp > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) > FAIL: gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) > > I don't see those failures on Linux. Really??? I do! I wonder whether it's a Linux version diff, or a compiler diff. What versions are you using? Mine are: %] msnyder<12>% gcc -v Reading specs from /usr/progressive/bin/../lib/gcc-lib/i386-pc-linux-gnu/2.9-gnu pro-98r1/specs gcc version 2.9-gnupro-98r1 %] msnyder<14>% uname -a Linux happy.cygnus.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown Here are my versions: delius:~$ gcc -v Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gcc version 2.95.2 19991024 (release) delius:~$ uname -a Linux delius.kettenis.local 2.2.14 #4 Thu Feb 3 02:07:27 CET 2000 i586 unknown It's got nothing to do with the Linux version, and probably everything with the compiler. Could you post the assembler output that your compiler generates for the following fragment: extern int foo (float f, float g); void bar (void) { foo (3.14, 2.72); } In my case this yields: .file "foo.c" .version "01.01" gcc2_compiled.: .section .rodata .align 4 .LC0: .long 0x402e147b .align 4 .LC1: .long 0x4048f5c3 .text .align 4 .globl bar .type bar,@function bar: pushl %ebp movl %esp,%ebp subl $8,%esp addl $-8,%esp flds .LC0 subl $4,%esp fstps (%esp) flds .LC1 subl $4,%esp fstps (%esp) call foo addl $16,%esp .L2: movl %ebp,%esp popl %ebp ret .Lfe1: .size bar,.Lfe1-bar .ident "GCC: (GNU) 2.95.2 19991024 (release)" The "subl $4,%esp" and "fstps (%esp)" instructions show that the arguments passed to foo() are both four bytes in size. So they can't be doubles. This is what I'd expect after reading the processor specific SystemV ABI, which AFAIK is used on Linux. Mark >From kevinb@cygnus.com Fri May 12 11:42:00 2000 From: Kevin Buettner To: msnyder@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: Promote float args on i386 (attn Hurd, Cygwin, DJGPP...) Date: Fri, 12 May 2000 11:42:00 -0000 Message-id: <1000512184223.ZM15618@ocotillo.lan> References: <200005120557.WAA05792@cleaver.cygnus.com> <200005121051.GAA14389@indy.delorie.com> <391C1E1C.2386@cygnus.com> <200005121633.SAA17193@landau.wins.uva.nl> <391C3ED8.894@cygnus.com> X-SW-Source: 2000-05/msg00210.html Content-length: 1375 On May 12, 10:26am, Michael Snyder wrote: > Mark Kettenis wrote: > > > Sure. > > make check RUNTESTFLAGS=callfuncs.exp > > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) > > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) > > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) > > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) > > FAIL: gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) > > > > I don't see those failures on Linux. > > Really??? I do! I wonder whether it's a Linux version diff, > or a compiler diff. What versions are you using? Mine are: > > %] msnyder<12>% gcc -v > Reading specs from > /usr/progressive/bin/../lib/gcc-lib/i386-pc-linux-gnu/2.9-gnu > pro-98r1/specs > gcc version 2.9-gnupro-98r1 > %] msnyder<14>% uname -a > Linux happy.cygnus.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 > i686 unknown FWIW, on my Linux box, I don't see the callfuncs.exp failures that you mention either. This is without your proposed patches. Here's the version info on my system... ocotillo:gdb$ gcc -v Reading specs from /ocotillo1/kev/devo-linux/bin/../lib/gcc-lib/i686-pc-linux-gnu/cygnus-2.96/specs gcc version cygnus-2.96 20000103 ocotillo:gdb$ uname -a Linux ocotillo.lan 2.2.15 #1 SMP Thu May 11 17:28:43 MST 2000 i686 unknown