* Re: authorship
[not found] ` <200005081809.OAA20154@delysid.gnu.org>
@ 2000-05-10 18:25 ` Andrew Cagney
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2000-05-10 18:25 UTC (permalink / raw)
To: Brian Youmans; +Cc: fnasser, dj, gdb-patches
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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
* 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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
* 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=<somepath> 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=<somepath> 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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
* 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 <<EOF
! fprintf_unfiltered (gdb_stdlog,
! "gdbarch_update: GDB_MULTI_ARCH = %d\\n",
! GDB_MULTI_ARCH);
! }
! EOF
# GET/SET
From ac131313@cygnus.com Thu May 11 05:04:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
* 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 <kettenis@wins.uva.nl>
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 <ac131313@cygnus.com>
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 <eliz@delorie.com>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
>
> 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 <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
> >
> > 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" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <tromey@cygnus.com>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com> 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 <fnasser@cygnus.com>
To: tromey@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: GDB needs a --cmdline option
Date: Thu, 11 May 2000 08:32:00 -0000
Message-id: <391AD28F.8C4E928F@cygnus.com>
References: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com> 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 <kettenis@wins.uva.nl>
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" <hjl@lucon.org>
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 <tromey@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: GDB needs a --cmdline option
Date: Thu, 11 May 2000 08:54:00 -0000
Message-id: <200005111554.IAA17794@ferrule.cygnus.com>
References: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <eliz@delorie.com>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
>
> 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 <eliz@delorie.com>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
>
> 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 <eliz@delorie.com>
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 <ac131313@cygnus.com>
>
> 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 <mdejong@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB needs a --cmdline option
Date: Thu, 11 May 2000 13:18:00 -0000
Message-id: <Pine.SOL.3.91.1000511131403.14281B-100000@cse.cygnus.com>
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 <fnasser@cygnus.com> 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 <fnasser@cygnus.com>
To: Mo DeJong <mdejong@cygnus.com>
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: <Pine.SOL.3.91.1000511131403.14281B-100000@cse.cygnus.com>
X-SW-Source: 2000-05/msg00187.html
Content-length: 1252
Mo DeJong wrote:
>
> On 11 May 2000, Tom Tromey wrote:
>
> > >>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> 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 <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
> >
> > 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 <tromey@cygnus.com>
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: <Pine.SOL.3.91.1000511131403.14281B-100000@cse.cygnus.com> <391B1780.23185181@cygnus.com>
X-SW-Source: 2000-05/msg00189.html
Content-length: 485
>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> 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 <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <ac131313@cygnus.com>
>
> 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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
>
> * 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 <msnyder@cygnus.com>
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 <msnyder@cleaver.cygnus.com>
* 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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <cagney@b1.cygnus.com>
* 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 <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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 <ac131313@cygnus.com>
> >
> > 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 <cagney@b1.cygnus.com>
* 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 <ac131313@cygnus.com>
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 <eliz@delorie.com>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
>
> > 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 <eliz@delorie.com>
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 <ac131313@cygnus.com>
>
> 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 <eliz@delorie.com>
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 <msnyder@cygnus.com>
> 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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: "Nick Duffek <Nick Duffek" <nsd@cygnus.com>
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
> <return> to continue, or q <return> 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 <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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: <Pine.LNX.4.10.10005101250570.18782-100000@abomination.cygnus.com> <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 <fnasser@cygnus.com>
> >
> > > 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 <kettenis@wins.uva.nl>
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 <term.h> together with the BSD
<curses.h>, 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 <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
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 <msnyder@cygnus.com>
> > 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 <msnyder@cygnus.com>
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 <kettenis@wins.uva.nl>
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 <msnyder@cygnus.com>
Eli Zaretskii wrote:
>
> > From: Michael Snyder <msnyder@cygnus.com>
> > 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 <msnyder@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <eliz@is.elta.co.il>, 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 <msnyder@cygnus.com> 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 <kettenis@wins.uva.nl>
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 <msnyder@cygnus.com>
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 <kevinb@cygnus.com>
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> <msnyder@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
^ permalink raw reply [flat|nested] 3+ messages in thread