From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Kevin Buettner Cc: Jim Blandy , Ulrich Drepper , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables Date: Wed, 08 Nov 2000 12:35:00 -0000 Message-id: References: <1001104012305.ZM6714@ocotillo.lan> <1001108013427.ZM19910@ocotillo.lan> X-SW-Source: 2000-11/msg00102.html The comparison of the executable's PC with the new process's PC seems fragile to me. We already know of two cases where this can happen (interpreters and dynamic executables); I wonder whether more will appear in the future. How would you feel about including *both* tests in svr4_relocate_main_executable --- both testing for a .interp section, and testing the DYNAMIC flag? Something like: if (exec file is DYNAMIC && exec file has no .interp && exec file's entry PC is different from new process's PC) then do the relocation This would avoid testing the PC when we run non-DYNAMIC programs with no .interp. (Which would be an old-fashioned statically linked program, right?) But either way, I feel I am nitpicking on shaky ground. Commit the change, with or without my suggestion, and we'll just see what happens. >From jimb@zwingli.cygnus.com Wed Nov 08 12:44:00 2000 From: Jim Blandy To: "Peter.Schauer" , Kevin Buettner , Elena Zannoni Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFD] objfiles.h, symfile.c, mdebugread.c: Fixes for Digital Unix. Date: Wed, 08 Nov 2000 12:44:00 -0000 Message-id: References: <200011080857.JAA27221@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-11/msg00103.html Content-length: 600 [Jim suggests using obj_private to cache pointers to the sections mdebug needs] > That's what I meant with: > > : > I am not sure if adding to sect_index_* and SECT_OFF_* is the way to go in > : > the general version, hiding those in obj_private might be > feasible. Okay. Kevin, Elena, what do you think? > We would need a mdebug section index table per objfile, but I am not sure if > obj_private is the right place. As obj_private is currently only used > by HPPA targets, it might be safe. obj_private looks custom-made for this case. By "HPPA targets", you mean "SOM executables", right? >From jimb@zwingli.cygnus.com Wed Nov 08 12:45:00 2000 From: Jim Blandy To: Daniel Berlin Cc: gdb-patches@sources.redhat.com Subject: Re: Reverted - June 5th patch Date: Wed, 08 Nov 2000 12:45:00 -0000 Message-id: References: X-SW-Source: 2000-11/msg00104.html Content-length: 3935 To be clear --- this change will re-bloat GDB when handling C++ code. We're just reverting to correct but inefficient behavior until we can get correct and efficient behavior. Daniel Berlin writes: > > As per Jim Blandy's request, I have reverted the June 5th change to > cache type names. > Changelog for revert patch: > 2000-11-07 Daniel Berlin > > * dwarf2read.c: Revert June 5th change for caching of types, > as per Jim Blandy's request. > > > Revert patch follows: > Index: ChangeLog > =================================================================== > RCS file: /cvs/src/src/gdb/ChangeLog,v > retrieving revision 1.753 > diff -c -3 -p -r1.753 ChangeLog > *** ChangeLog 2000/11/06 23:12:29 1.753 > --- ChangeLog 2000/11/08 02:47:34 > *************** > *** 1,3 **** > --- 1,8 ---- > + 2000-11-07 Daniel Berlin > + > + * dwarf2read.c: Revert June 5th change for caching of types, > + as per Jim Blandy's request. > + > 2000-11-06 Fernando Nasser > > * wrapper.c (gdb_value_assign): New function. Longjump-free > Index: dwarf2read.c > =================================================================== > RCS file: /cvs/src/src/gdb/dwarf2read.c,v > retrieving revision 1.17 > diff -c -3 -p -r1.17 dwarf2read.c > *** dwarf2read.c 2000/11/03 22:38:38 1.17 > --- dwarf2read.c 2000/11/08 02:47:35 > *************** static struct abbrev_info *dwarf2_abbrev > *** 275,285 **** > > static struct die_info *die_ref_table[REF_HASH_SIZE]; > > - #ifndef TYPE_HASH_SIZE > - #define TYPE_HASH_SIZE 4096 > - #endif > - static struct type *dwarf2_cached_types[TYPE_HASH_SIZE]; > - > /* Obstack for allocating temporary storage used during symbol reading. */ > static struct obstack dwarf2_tmp_obstack; > > --- 275,280 ---- > *************** read_comp_unit (char *info_ptr, bfd *abf > *** 2901,2907 **** > char *cur_ptr; > int nesting_level; > > ! /* Reset die reference table and cached types table; we are > building new ones now. */ > dwarf2_empty_hash_tables (); > > --- 2896,2902 ---- > char *cur_ptr; > int nesting_level; > > ! /* Reset die reference table; we are > building new ones now. */ > dwarf2_empty_hash_tables (); > > *************** tag_type_to_type (struct die_info *die, > *** 4528,4565 **** > } > else > { > ! struct attribute *attr; > ! attr = dwarf_attr (die, DW_AT_name); > ! if (attr && DW_STRING (attr)) > ! { > ! char *attrname=DW_STRING (attr); > ! unsigned long hashval=hash(attrname, strlen(attrname)) % TYPE_HASH_SIZE; > ! > ! if (dwarf2_cached_types[hashval] != NULL) > ! { > ! const char *nameoftype; > ! nameoftype = TYPE_NAME(dwarf2_cached_types[hashval]) == NULL ? TYPE_TAG_NAME(dwarf2_cached_types[hashval]) : TYPE_NAME(dwarf2_cached_types[hashval]); > ! if (strcmp(attrname, nameoftype) == 0) > ! { > ! die->type=dwarf2_cached_types[hashval]; > ! } > ! else > ! { > ! read_type_die (die, objfile, cu_header); > ! dwarf2_cached_types[hashval] = die->type; > ! } > ! } > ! else > ! { > ! read_type_die (die, objfile, cu_header); > ! dwarf2_cached_types[hashval] = die->type; > ! } > ! } > ! else > ! { > ! read_type_die (die, objfile, cu_header); > ! } > ! > if (!die->type) > { > dump_die (die); > --- 4523,4529 ---- > } > else > { > ! read_type_die (die, objfile, cu_header); > if (!die->type) > { > dump_die (die); > *************** static void > *** 5606,5612 **** > dwarf2_empty_hash_tables (void) > { > memset (die_ref_table, 0, sizeof (die_ref_table)); > - memset (dwarf2_cached_types, 0, sizeof(dwarf2_cached_types)); > } > > static unsigned int > --- 5570,5575 ---- > > >From jtc@redback.com Wed Nov 08 13:09:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: [RFA]: Fix partial memory transfers Date: Wed, 08 Nov 2000 13:09:00 -0000 Message-id: <5mwveegoib.fsf@jtc.redback.com> X-SW-Source: 2000-11/msg00105.html Content-length: 5235 I submit the enclosed patch to target.c for approval. My recent commit to move the dcache on top of the target xfer_memory vector introduced a bug such that target_partial_xfer_memory() would always perform a complete transfer, which defeated the entire purpose of that function. The enclosed patch fixes do_xfer_memory(), the low-level function that calls the xfer_memory vector function(s), to perform only one transfer. The dcache already has the logic that will call do_xfer_memory multiple times if it returns a partial transfer. This patch also fixes up comments for the *xfer_memory* functions. Some have been wrong/misleading for a very long time. This patch also includes a bug fix from Nick, which caused me to look at and fine the above bug. I'm including it in this patch because he retracted the bug fix when I mentioned this patch was coming. --jtc 2000-11-08 J.T. Conklin * target.c (do_xfer_memory): Only perform a single memory transfer instead of iterating to tranfer the entire region. Higher layers are expected to call this function multiple times for partial transfers. (target_xfer_memory_partial): Remove unused local variables. 2000-11-07 Nick Duffek * target.c (target_xfer_memory_partial): Return bytes transferred instead of 0. Index: target.c =================================================================== RCS file: /cvs/src/src/gdb/target.c,v retrieving revision 1.14 diff -c -r1.14 target.c *** target.c 2000/11/03 22:00:56 1.14 --- target.c 2000/11/08 20:53:15 *************** *** 837,851 **** return target_xfer_memory (memaddr, myaddr, len, 1); } ! /* Move memory to or from the targets. Iterate until all of it has ! been moved, if necessary. The top target gets priority; anything ! it doesn't want, is offered to the next one down, etc. Note the ! business with curlen: if an early target says "no, but I have a ! boundary overlapping this xfer" then we shorten what we offer to ! the subsequent targets so the early guy will get a chance at the ! tail before the subsequent ones do. ! Result is 0 or errno value. */ int do_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write) --- 837,846 ---- return target_xfer_memory (memaddr, myaddr, len, 1); } ! /* Move memory to or from the targets. The top target gets priority; ! if it cannot handle it, it is offered to the next one down, etc. ! Result is -1 on error, or the number of bytes transfered. */ int do_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write) *************** *** 863,880 **** 0. */ errno = 0; ! /* The quick case is that the top target does it all. */ res = current_target.to_xfer_memory (memaddr, myaddr, len, write, ¤t_target); - if (res == len) - return len; - - if (res > 0) - goto bump; - /* If res <= 0 then we call it again in the loop. Ah well. */ ! while (len > 0) { for (item = target_stack; item; item = item->next) { t = item->target_ops; --- 858,871 ---- 0. */ errno = 0; ! /* The quick case is that the top target can handle the transfer. */ res = current_target.to_xfer_memory (memaddr, myaddr, len, write, ¤t_target); ! if (res <= 0) { + /* If res <= 0 then we call it again in the loop. Ah well. */ + for (item = target_stack; item; item = item->next) { t = item->target_ops; *************** *** 889,907 **** } if (res <= 0) ! { ! return -1; ! } ! bump: ! done += res; ! memaddr += res; ! myaddr += res; ! len -= res; } ! ! return done; } static int target_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write) { --- 880,897 ---- } if (res <= 0) ! return -1; } ! ! return res; } + + /* Perform a memory transfer. Iterate until the entire region has + been transfered. + + Result is 0 or errno value. */ + static int target_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write) { *************** *** 936,953 **** return 0; /* We managed to cover it all somehow. */ } ! /* Perform a partial memory transfer. */ static int target_xfer_memory_partial (CORE_ADDR memaddr, char *myaddr, int len, int write_p, int *err) { int res; - int err_res; - int len_res; - struct target_ops *t; - struct target_stack_item *item; /* Zero length requests are ok and require no work. */ if (len == 0) --- 926,941 ---- return 0; /* We managed to cover it all somehow. */ } + + /* Perform a partial memory transfer. ! Result is -1 on error, or the number of bytes transfered. */ static int target_xfer_memory_partial (CORE_ADDR memaddr, char *myaddr, int len, int write_p, int *err) { int res; /* Zero length requests are ok and require no work. */ if (len == 0) *************** *** 968,974 **** } *err = 0; ! return 0; } int --- 956,962 ---- } *err = 0; ! return res; } int -- J.T. Conklin RedBack Networks >From drepper@redhat.com Wed Nov 08 13:25:00 2000 From: Ulrich Drepper To: Kevin Buettner Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables Date: Wed, 08 Nov 2000 13:25:00 -0000 Message-id: References: <1001104012305.ZM6714@ocotillo.lan> <1001108201004.ZM22294@ocotillo.lan> X-SW-Source: 2000-11/msg00106.html Content-length: 553 Kevin Buettner writes: > Either way, the patch currently on the table should go in since it is > needed to handle the case of DSOs (and perhaps other executables) > which lack an interpreter section. It is definitely *much* better than the current situation and it is not disturbing any other way gdb is used. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ >From drepper@redhat.com Wed Nov 08 13:26:00 2000 From: Ulrich Drepper To: Jim Blandy Cc: Kevin Buettner , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables Date: Wed, 08 Nov 2000 13:26:00 -0000 Message-id: References: <1001104012305.ZM6714@ocotillo.lan> <1001108013427.ZM19910@ocotillo.lan> X-SW-Source: 2000-11/msg00107.html Content-length: 590 Jim Blandy writes: > The comparison of the executable's PC with the new process's PC seems > fragile to me. We already know of two cases where this can happen > (interpreters and dynamic executables); I wonder whether more will > appear in the future. Why is it fragile? This is the same mechanism the ld.so is based on. It is guaranteed to work. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ >From kevinb@cygnus.com Wed Nov 08 13:30:00 2000 From: Kevin Buettner To: "Peter.Schauer" , Elena Zannoni , Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFD] objfiles.h, symfile.c, mdebugread.c: Fixes for Digital Unix. Date: Wed, 08 Nov 2000 13:30:00 -0000 Message-id: <1001108213023.ZM22461@ocotillo.lan> References: <200011080857.JAA27221@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-11/msg00108.html Content-length: 497 On Nov 8, 3:40pm, Jim Blandy wrote: > [Jim suggests using obj_private to cache pointers to the sections > mdebug needs] > > > That's what I meant with: > > > > : > I am not sure if adding to sect_index_* and SECT_OFF_* is the way to go in > > : > the general version, hiding those in obj_private might be > > feasible. > > Okay. Kevin, Elena, what do you think? Using obj_private to keep a map from sc* indices to section indices (or something along these lines) sounds right to me. Kevin >From bje@redhat.com Wed Nov 08 15:12:00 2000 From: Ben Elliston To: gdb-patches@sources.redhat.com Subject: Spelling corrections to sim-fpu.h Date: Wed, 08 Nov 2000 15:12:00 -0000 Message-id: <200011082311.eA8NBme00638@scooby.cygnus.com> X-SW-Source: 2000-11/msg00109.html Content-length: 2963 FYI, I am checking in the following patch to correct some spelling errors/typos in sim/common/sim-fpu.h. Ben *** sim-fpu.h 1999/04/16 01:34:57 1.1.1.1 --- sim-fpu.h 2000/11/08 23:09:55 *************** *** 164,172 **** When converting from the sim_fpu internal type to 32/64 bit packed format, the operation may result in a loss of precision. The configuration macro WITH_FPU_CONVERSION controls this. By default, ! silent round to nearest is performed. Alternativly, round up, round down and round to zero can be performed. In a simulator ! emulating exact FPU behavour, sim_fpu_round_{32,64} should be called before packing the sim_fpu value. */ INLINE_SIM_FPU (void) sim_fpu_32to (sim_fpu *f, unsigned32 s); --- 164,172 ---- When converting from the sim_fpu internal type to 32/64 bit packed format, the operation may result in a loss of precision. The configuration macro WITH_FPU_CONVERSION controls this. By default, ! silent round to nearest is performed. Alternatively, round up, round down and round to zero can be performed. In a simulator ! emulating exact FPU behavior, sim_fpu_round_{32,64} should be called before packing the sim_fpu value. */ INLINE_SIM_FPU (void) sim_fpu_32to (sim_fpu *f, unsigned32 s); *************** *** 189,195 **** INLINE_SIM_FPU (void) sim_fpu_fractionto (sim_fpu *f, int sign, int normal_exp, unsigned64 fraction, int precision); ! /* Reverse operaton. If S is a non-zero number, discards the implied leading one and returns PRECISION fraction bits. No rounding is performed. */ INLINE_SIM_FPU (unsigned64) sim_fpu_tofraction (const sim_fpu *s, int precision); --- 189,195 ---- INLINE_SIM_FPU (void) sim_fpu_fractionto (sim_fpu *f, int sign, int normal_exp, unsigned64 fraction, int precision); ! /* Reverse operation. If S is a non-zero number, discards the implied leading one and returns PRECISION fraction bits. No rounding is performed. */ INLINE_SIM_FPU (unsigned64) sim_fpu_tofraction (const sim_fpu *s, int precision); *************** *** 210,216 **** ! /* Arrithmetic operators. FIXME: In the future, additional arguments ROUNDING and BITSIZE may be added. */ --- 210,216 ---- ! /* Arithmetic operators. FIXME: In the future, additional arguments ROUNDING and BITSIZE may be added. */ *************** *** 283,289 **** /* Conversion of internal sim_fpu type to host double format. ! For debuging/tracing only. A SNaN is never returned. */ /* INLINE_SIM_FPU (float) sim_fpu_2f (const sim_fpu *f); */ INLINE_SIM_FPU (double) sim_fpu_2d (const sim_fpu *d); --- 283,289 ---- /* Conversion of internal sim_fpu type to host double format. ! For debugging/tracing only. A SNaN is never returned. */ /* INLINE_SIM_FPU (float) sim_fpu_2f (const sim_fpu *f); */ INLINE_SIM_FPU (double) sim_fpu_2d (const sim_fpu *d); >From bje@redhat.com Wed Nov 08 15:18:00 2000 From: Ben Elliston To: gdb-patches@sources.redhat.com Subject: [Sim] Patch for fp constants Date: Wed, 08 Nov 2000 15:18:00 -0000 Message-id: <200011082317.eA8NHxR00680@scooby.cygnus.com> X-SW-Source: 2000-11/msg00110.html Content-length: 951 Two of the pre-defined floating point constants (namely, one and two) are incorrectly defined in sim/common/sim-fpu.c. They should have (normalised) exponents of zero and one, respectively. In prior consultation with Andrew Cagney, I am checking these fixes in now. No existing simulator uses these constants. 2000-11-09 Ben Elliston * sim-fpu.c (sim_fpu_one): Set exponent to 0. (sim_fpu_two): Set exponent to 1. diff -u -r1.1.1.2 sim-fpu.c --- sim-fpu.c 1999/09/22 03:28:07 1.1.1.2 +++ sim-fpu.c 2000/11/08 23:15:59 @@ -2456,10 +2456,10 @@ sim_fpu_class_qnan, }; const sim_fpu sim_fpu_one = { - sim_fpu_class_number, 0, IMPLICIT_1, 1 + sim_fpu_class_number, 0, IMPLICIT_1, 0 }; const sim_fpu sim_fpu_two = { - sim_fpu_class_number, 0, IMPLICIT_1, 2 + sim_fpu_class_number, 0, IMPLICIT_1, 1 }; const sim_fpu sim_fpu_max32 = { sim_fpu_class_number, 0, LSMASK64 (NR_FRAC_GUARD, NR_GUARDS32), NORMAL_EXPMAX32 >From msnyder@cygnus.com Wed Nov 08 15:58:00 2000 From: Michael Snyder To: gdb-patches@sources.redhat.com Subject: [PATCH] spelling correction in gdbarch. Date: Wed, 08 Nov 2000 15:58:00 -0000 Message-id: <200011082358.PAA20756@cleaver.cygnus.com> X-SW-Source: 2000-11/msg00111.html Content-length: 7066 2000-11-08 Michael Snyder * gdbarch.sh: Spelling correction: registrary -> registry. * gdbarch.c: Ditto. Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.47 diff -c -r1.47 gdbarch.sh *** gdbarch.sh 2000/10/30 21:50:57 1.47 --- gdbarch.sh 2000/11/08 23:57:58 *************** *** 1470,1476 **** cat <next); (*curr) = XMALLOC (struct gdbarch_data_registration); (*curr)->next = NULL; (*curr)->init = init; (*curr)->data = XMALLOC (struct gdbarch_data); ! (*curr)->data->index = gdbarch_data_registrary.nr++; return (*curr)->data; } --- 1500,1513 ---- register_gdbarch_data (gdbarch_data_ftype *init) { struct gdbarch_data_registration **curr; ! for (curr = &gdbarch_data_registry.registrations; (*curr) != NULL; curr = &(*curr)->next); (*curr) = XMALLOC (struct gdbarch_data_registration); (*curr)->next = NULL; (*curr)->init = init; (*curr)->data = XMALLOC (struct gdbarch_data); ! (*curr)->data->index = gdbarch_data_registry.nr++; return (*curr)->data; } *************** *** 1518,1526 **** init_gdbarch_data (struct gdbarch *gdbarch) { struct gdbarch_data_registration *rego; ! gdbarch->nr_data = gdbarch_data_registrary.nr + 1; gdbarch->data = xmalloc (sizeof (void*) * gdbarch->nr_data); ! for (rego = gdbarch_data_registrary.registrations; rego != NULL; rego = rego->next) { --- 1518,1526 ---- init_gdbarch_data (struct gdbarch *gdbarch) { struct gdbarch_data_registration *rego; ! gdbarch->nr_data = gdbarch_data_registry.nr + 1; gdbarch->data = xmalloc (sizeof (void*) * gdbarch->nr_data); ! for (rego = gdbarch_data_registry.registrations; rego != NULL; rego = rego->next) { *************** *** 1543,1549 **** ! /* Keep a registrary of swapped data required by GDB modules. */ struct gdbarch_swap { --- 1543,1549 ---- ! /* Keep a registry of swapped data required by GDB modules. */ struct gdbarch_swap { *************** *** 1560,1572 **** struct gdbarch_swap_registration *next; }; ! struct gdbarch_swap_registrary { int nr; struct gdbarch_swap_registration *registrations; }; ! struct gdbarch_swap_registrary gdbarch_swap_registrary = { 0, NULL, }; --- 1560,1572 ---- struct gdbarch_swap_registration *next; }; ! struct gdbarch_swap_registry { int nr; struct gdbarch_swap_registration *registrations; }; ! struct gdbarch_swap_registry gdbarch_swap_registry = { 0, NULL, }; *************** *** 1577,1583 **** gdbarch_swap_ftype *init) { struct gdbarch_swap_registration **rego; ! for (rego = &gdbarch_swap_registrary.registrations; (*rego) != NULL; rego = &(*rego)->next); (*rego) = XMALLOC (struct gdbarch_swap_registration); --- 1577,1583 ---- gdbarch_swap_ftype *init) { struct gdbarch_swap_registration **rego; ! for (rego = &gdbarch_swap_registry.registrations; (*rego) != NULL; rego = &(*rego)->next); (*rego) = XMALLOC (struct gdbarch_swap_registration); *************** *** 1593,1599 **** { struct gdbarch_swap_registration *rego; struct gdbarch_swap **curr = &gdbarch->swap; ! for (rego = gdbarch_swap_registrary.registrations; rego != NULL; rego = rego->next) { --- 1593,1599 ---- { struct gdbarch_swap_registration *rego; struct gdbarch_swap **curr = &gdbarch->swap; ! for (rego = gdbarch_swap_registry.registrations; rego != NULL; rego = rego->next) { *************** *** 1632,1638 **** } ! /* Keep a registrary of the architectures known by GDB. */ struct gdbarch_registration { --- 1632,1638 ---- } ! /* Keep a registry of the architectures known by GDB. */ struct gdbarch_registration { *************** *** 1643,1649 **** struct gdbarch_registration *next; }; ! static struct gdbarch_registration *gdbarch_registrary = NULL; static void append_name (const char ***buf, int *nr, const char *name) --- 1643,1649 ---- struct gdbarch_registration *next; }; ! static struct gdbarch_registration *gdbarch_registry = NULL; static void append_name (const char ***buf, int *nr, const char *name) *************** *** 1664,1670 **** int nr_arches = 0; const char **arches = NULL; struct gdbarch_registration *rego; ! for (rego = gdbarch_registrary; rego != NULL; rego = rego->next) { --- 1664,1670 ---- int nr_arches = 0; const char **arches = NULL; struct gdbarch_registration *rego; ! for (rego = gdbarch_registry; rego != NULL; rego = rego->next) { *************** *** 1703,1709 **** internal_error ("gdbarch: Attempt to register unknown architecture (%d)", bfd_architecture); } /* Check that we haven't seen this architecture before */ ! for (curr = &gdbarch_registrary; (*curr) != NULL; curr = &(*curr)->next) { --- 1703,1709 ---- internal_error ("gdbarch: Attempt to register unknown architecture (%d)", bfd_architecture); } /* Check that we haven't seen this architecture before */ ! for (curr = &gdbarch_registry; (*curr) != NULL; curr = &(*curr)->next) { *************** *** 1800,1806 **** /* A default for abfd? */ /* Find the target that knows about this architecture. */ ! for (rego = gdbarch_registrary; rego != NULL; rego = rego->next) if (rego->bfd_architecture == info.bfd_architecture) --- 1800,1806 ---- /* A default for abfd? */ /* Find the target that knows about this architecture. */ ! for (rego = gdbarch_registry; rego != NULL; rego = rego->next) if (rego->bfd_architecture == info.bfd_architecture) >From ac131313@cygnus.com Wed Nov 08 22:47:00 2000 From: Andrew Cagney To: Volker Borchert , GDB Patches Subject: [patch] Fix --target=vax-dec-vms5.5; Was: [Bug-gdb] gdb-5.0: cross build for VAX on Solaris fails (patch included) Date: Wed, 08 Nov 2000 22:47:00 -0000 Message-id: <3A0A46D4.31BAFED7@cygnus.com> References: <200011081302.eA8D2EU17717@Iapetos.teknon.de> X-SW-Source: 2000-11/msg00112.html Content-length: 2097 FYI, I've checked in the attatched which fixes a number of errors/warnings for the target vax-dec-vms5.5. I don't know if it actually works :-) Andrew Thu Nov 9 17:16:29 2000 Andrew Cagney * MAINTAINERS: Specify the vax-dec-vms5.5 target tupple. * vax-tdep.c: Include "gdbcore.h", "frame.h" and "value.h". (vax_print_insn): Change ``d'' to a const char pointer. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.53 diff -p -r1.53 MAINTAINERS *** MAINTAINERS 2000/10/20 08:21:45 1.53 --- MAINTAINERS 2000/11/09 06:37:17 *************** maintainer works with the native maintai *** 92,98 **** tic80 maintenance only (tic80-coff) v850 maintenance only (v850-elf) ! vax maintenance only (?) w65 maintenance only (?) z8k maintenance only (?) --- 92,98 ---- tic80 maintenance only (tic80-coff) v850 maintenance only (v850-elf) ! vax maintenance only (vax-dec-vms5.5) w65 maintenance only (?) z8k maintenance only (?) Index: vax-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/vax-tdep.c,v retrieving revision 1.2 diff -p -r1.2 vax-tdep.c *** vax-tdep.c 2000/07/30 01:48:28 1.2 --- vax-tdep.c 2000/11/09 06:37:19 *************** *** 21,26 **** --- 21,29 ---- #include "defs.h" #include "symtab.h" #include "opcode/vax.h" + #include "gdbcore.h" + #include "frame.h" + #include "value.h" /* Vax instructions are never longer than this. */ #define MAXLEN 62 *************** vax_print_insn (CORE_ADDR memaddr, disas *** 80,86 **** unsigned char buffer[MAXLEN]; register int i; register unsigned char *p; ! register char *d; int status = (*info->read_memory_func) (memaddr, buffer, MAXLEN, info); if (status != 0) --- 83,89 ---- unsigned char buffer[MAXLEN]; register int i; register unsigned char *p; ! const char *d; int status = (*info->read_memory_func) (memaddr, buffer, MAXLEN, info); if (status != 0) >From ac131313@cygnus.com Wed Nov 08 23:25:00 2000 From: Andrew Cagney To: Scott Bambrough Cc: gdb-patches@sources.redhat.com, Philip Blundell Subject: Re: disable gdbserver for cross builds Date: Wed, 08 Nov 2000 23:25:00 -0000 Message-id: <3A0A4FE0.1C31355E@cygnus.com> References: <013701c02c27$955caf80$LocalHost@netbackup> X-SW-Source: 2000-11/msg00113.html Content-length: 3437 I think there are several cases where gdbserver could be configured: --build=X --host=X --target=X For X using procfs/ptrace Native debugger --build=X --host=X --target=Y For Y using libsim.a Cross debugger --build=X --host=Y --target=Y For Y using procfs/ptrace Canadian cross of native debugger --build=X --host=Y --target=Z For Z using libsim.a Canadian cross of cross debugger I don't think that the configury should be trying to do things like: --build=X --host=X --target=Y For Y using procfs/ptrace Some people call this host-X-host A host=X/target=Y procfs/ptrace gdbserver couldn't do anything useful (well I guess you could NFS mount Y's /proc :-). A host=Y/target=Y procfs/ptrace gdbserver is counter-intuitive, it is better handled by the user expalicitly configuring/building a canadian-cross. I should note that in a number of the above cases (build=X/host=Y/target=Y and build=X/host=Y/target=Z) there is the potential for building both a procfs/ptrace and libsim gdbserver (example would be ppc-linux). So I guess the two things to do are: o reach consensus on which of the above are useful o fix the configury to match I should also mention that gdbserver is heading for a period when it is going to struggle to survive - multi-arch makes it difficult to build a traditional gdbserver. Scott Bambrough wrote: > [...] > I should be able to add gdbserver to configdirs in configure.tgt, and have > it built automatically. This used to work AFAIK. Somewhere along the line, > it got broken. Don't know how, or when, and I really don't care. The > configdirs macro from configure.tgt is never used to configure any > subdirectories AFAICT. I think this is wrong; it prevents gdbserver from > being built for any target that adds it to configdirs, it prevents the > rdi-share directory from being configured automatically for embedded arm > targets and the nlm directory from being configured for any netware targets. > IMHO if building gdbserver automatically is not desired for a particular > target, then the appropriate thing to do is to remove it from configdirs in > configure.tgt. I don't think that gdb/gdbserver should be configured unless the target / native files explicitly enable it. This is because, at present, it isn't enabled and this will have the likely effect of breaking random target builds :-( > > There is a warning in the README in the gdbserver subdirectory stating that > it currently doesn't build in a cross-compilation environment. I don't > think it makes sense to build other than with host=target. It has to run on > the same environment it was built for. Thus enabling the statement that > removes gdbserver from configdirs if host != target is a valid thing to do. > This statement was removed to allow gdbserver to support simulators > (ChangeLog-97). Is this currently possible? If so it needs to be > considered. > > This issue has been around since July, and needs to be dealt with. I think > there is good reason for this change, and I haven't seen any compelling > arguments why it shouldn't be made. I've included pointers to my earlier > RFC and my responses to questions about the patch included there. > > http://sources.redhat.com/ml/gdb-patches/2000-07/msg00375.html > http://sources.redhat.com/ml/gdb-patches/2000-08/msg00007.html > http://sources.redhat.com/ml/gdb-patches/2000-08/msg00009.html > enjoy, Andrew >From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Nov 09 01:54:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] Implement auto-solib-add for AIX3/4, cleanup of shlib code. Date: Thu, 09 Nov 2000 01:54:00 -0000 Message-id: <200011090953.KAA28740@reisser.regent.e-technik.tu-muenchen.de> References: <1001106061910.ZM14800@ocotillo.lan> X-SW-Source: 2000-11/msg00114.html Content-length: 2245 Committed. > Add auto-solib-add support for AIX, remove obsolete and unused > SOLIB_SYMBOLS_MANUAL code, cleanup of AIX shared library handling code. > * rs6000-nat.c (vmap_symtab): Do not try to modify offsets > if symbols are not yet loaded. > (vmap_add_symbols): New function to add symbols for a vmap entry. > (add_vmap): Turn errors into warnings, return NULL vmap upon > failure. Add symbols via vmap_add_symbols only if requested. > (xcoff_relocate_core): Allow debugging of core files without an > executable file. Handle NULL returns from add_vmap gracefully. > * xcoffsolib.c (solib_add): Remove, no longer needed. > (solib_info): Do not check for new shared libraries if there is no > inferior process. > (sharedlibrary_command): Made static. > Do not check for new shared libraries if there is no inferior process. > Add symbols for requested shared libraries via vmap_add_symbols. > (_initialize_solib): Add `set auto-solib-add' command. > * xcoffsolib.h (vmap_add_symbols): Add prototype declaration. > > * config/rs6000/tm-rs6000.h (PC_LOAD_SEGMENT): Move from here ... > * config/rs6000/nm-rs6000.h: ... to here, this is an AIX native > feature. > * config/powerpc/tm-macos.h, config/powerpc/tm-ppc-eabi.h, > config/powerpc/tm-ppc-nw.h, config/rs6000/tm-rs6000ly.h: > Remove #undef PC_LOAD_SEGMENT. > * config/powerpc/aix.mt, config/rs6000/aix4.mt, config/rs6000/rs6000.mt > (TDEPFILES): Move xcoffsolib.o from here ... > * config/powerpc/aix.mh, config/rs6000/aix4.mh, config/rs6000/rs6000.mh > (NATDEPFILES): ... to here, xcoffsolib.o contains AIX native code > only. > * rs6000-tdep.c: Remove #include xcoffsolib.h, no longer needed. > * xcoffsolib.h (xcoff_relocate_symtab_hook): Remove declaration. > * rs6000-nat.c (_initialize_core_rs6000): Remove setting of > xcoff_relocate_symtab_hook, no longer needed. > * xcoffsolib.c (solib_info, sharedlibrary_command): Remove > xcoff_relocate_symtab_hook indirection, call xcoff_relocate_symtab > directly, as xcoffsolib.c is now compiled in native AIX configurations > only. > * Makefile.in: Update dependencies for rs6000-tdep.o, rs6000-nat.o > and xcoffsolib.o. -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From orjan.friberg@axis.com Thu Nov 09 02:21:00 2000 From: Orjan Friberg To: gdb-patches@sourceware.cygnus.com Subject: Getting hold of a bfd in _initialize__tdep Date: Thu, 09 Nov 2000 02:21:00 -0000 Message-id: <3A0A7A68.D285F405@axis.com> X-SW-Source: 2000-11/msg00115.html Content-length: 774 When defining the tm_print_insn parameter in _initialize_cris_tdep (port to be submitted), I need a bfd (not just bfd_arch_info) to supply to a function (cris_get_disassembler) which gives me the correct disassembler. However, I can't seem to get hold of one. Also, no one seems to be using the disassembler (bfd *) function in dis-asm.h, which makes me suspicious as to its applicability. The rs6000 target does make use of the info.abfd in its gdbarch_init () function, though I can't verify that it's actually != 0 inside function. Should I base the choice of disassembler on something else than the actual bfd, or is there a proper way to get hold of it? -- Orjan Friberg E-mail: orjan.friberg@axis.com Axis Communications AB Phone: +46 46 272 17 68 >From msnyder@redhat.com Thu Nov 09 10:25:00 2000 From: Michael Snyder To: Orjan Friberg Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Getting hold of a bfd in _initialize__tdep Date: Thu, 09 Nov 2000 10:25:00 -0000 Message-id: <3A0AEC03.7B4E@redhat.com> References: <3A0A7A68.D285F405@axis.com> X-SW-Source: 2000-11/msg00116.html Content-length: 807 Orjan Friberg wrote: > > When defining the tm_print_insn parameter in _initialize_cris_tdep (port > to be submitted), I need a bfd (not just bfd_arch_info) to supply to a > function (cris_get_disassembler) which gives me the correct > disassembler. However, I can't seem to get hold of one. Also, no one > seems to be using the disassembler (bfd *) function in dis-asm.h, which > makes me suspicious as to its applicability. The rs6000 target does make > use of the info.abfd in its gdbarch_init () function, though I can't > verify that it's actually != 0 inside function. > > Should I base the choice of disassembler on something else than the > actual bfd, or is there a proper way to get hold of it? With appologies to the gods of software engineering, you could use the global variable "exec_bfd". >From hans-peter.nilsson@axis.com Thu Nov 09 10:36:00 2000 From: Hans-Peter Nilsson To: gdb-patches@sourceware.cygnus.com Cc: orjan.friberg@axis.com Subject: Re: Getting hold of a bfd in _initialize__tdep Date: Thu, 09 Nov 2000 10:36:00 -0000 Message-id: <200011091836.TAA29203@ignucius.axis.se> References: <3A0A7A68.D285F405@axis.com> X-SW-Source: 2000-11/msg00117.html Content-length: 874 > Date: Thu, 09 Nov 2000 11:20:24 +0100 > From: Orjan Friberg > When defining the tm_print_insn parameter in _initialize_cris_tdep (port > to be submitted), I need a bfd (not just bfd_arch_info) to supply to a > function (cris_get_disassembler) which gives me the correct > disassembler. Let me just add that it actually *is* traits of the file format (really: the bfd_target) that cris_get_disassembler uses: whether or not to add register-prefix to registers depending on symbol_leading_char. I was obviously wrong thinking that the function disassemble declared in include/dis-asm.h was used also by gdb (so a bfd was handy). But somehow it just seemed natural, that for all common cases there is a bfd somewhere close by, to use by gdb target initialization functions. (Or that there was something that should be fixed to do that. ;-) brgds, H-P >From jimb@zwingli.cygnus.com Thu Nov 09 13:29:00 2000 From: Jim Blandy To: Orjan Friberg Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Getting hold of a bfd in _initialize__tdep Date: Thu, 09 Nov 2000 13:29:00 -0000 Message-id: References: <3A0A7A68.D285F405@axis.com> X-SW-Source: 2000-11/msg00118.html Content-length: 1038 > When defining the tm_print_insn parameter in _initialize_cris_tdep (port > to be submitted), I need a bfd (not just bfd_arch_info) to supply to a > function (cris_get_disassembler) which gives me the correct > disassembler. However, I can't seem to get hold of one. Also, no one > seems to be using the disassembler (bfd *) function in dis-asm.h, which > makes me suspicious as to its applicability. The rs6000 target does make > use of the info.abfd in its gdbarch_init () function, though I can't > verify that it's actually != 0 inside function. > > Should I base the choice of disassembler on something else than the > actual bfd, or is there a proper way to get hold of it? The _initialize functions are called before GDB has opened any BFD's, so they can't do anything smart about tm_print_insn. What you can do instead is set tm_print_insn to point to a function in your tdep file which calls the right function from libopcodes.a; this is what the MIPS target does. Shouldn't tm_print_insn be replaced with a gdbarch method? >From jtc@redback.com Thu Nov 09 14:59:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: Move shared library support for NetBSD targets Date: Thu, 09 Nov 2000 14:59:00 -0000 Message-id: <5mk8acda5u.fsf@jtc.redback.com> X-SW-Source: 2000-11/msg00119.html Content-length: 8662 As Mike recently did for the Linux targets, I've moved shared library objects from NATDEPFILES to TDEPFILES for the NetBSD targets. --jtc 2000-11-09 J.T. Conklin * config/i386/nbsd.mh: Remove solib.o, solib-svr4.o from NATDEPFILES. * config/i386/nbsdelf.mh: Likewise. * config/m68k/nbsd.mh: Likewise. * config/ns32k/nbsd.mh: Likewise. * config/powerpc/nbsd.mh: Likewise. * config/sparc/nbsd.mh: Likewise. * config/sparc/nbsdelf.mh: Likewise. * config/i386/nbsd.mt: Add solib.o, solib-svr4.o to TDEPFILES. * config/i386/nbsdelf.mt: Likewise. * config/m68k/nbsd.mt: Likewise. * config/ns32k/nbsd.mt: Likewise. * config/powerpc/nbsd.mt: Likewise. * config/sparc/nbsd.mt: Likewise. Index: config/i386/nbsd.mh =================================================================== RCS file: /cvs/src/src/gdb/config/i386/nbsd.mh,v retrieving revision 1.5 diff -c -r1.5 nbsd.mh *** nbsd.mh 2000/10/24 20:05:35 1.5 --- nbsd.mh 2000/11/09 22:42:17 *************** *** 1,6 **** # Host: Intel 386 running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \ ! i386nbsd-nat.o solib.o solib-svr4.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h --- 1,5 ---- # Host: Intel 386 running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386nbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h Index: config/i386/nbsd.mt =================================================================== RCS file: /cvs/src/src/gdb/config/i386/nbsd.mt,v retrieving revision 1.4 diff -c -r1.4 nbsd.mt *** nbsd.mt 2000/09/07 20:08:40 1.4 --- nbsd.mt 2000/11/09 22:42:17 *************** *** 1,5 **** # Target: Intel 386 running NetBSD ! TDEPFILES= i386-tdep.o i387-tdep.o i386nbsd-tdep.o TM_FILE= tm-nbsd.h GDBSERVER_DEPFILES= low-nbsd.o --- 1,5 ---- # Target: Intel 386 running NetBSD ! TDEPFILES= i386-tdep.o i387-tdep.o i386nbsd-tdep.o solib.o solib-svr4.o TM_FILE= tm-nbsd.h GDBSERVER_DEPFILES= low-nbsd.o Index: config/i386/nbsdelf.mh =================================================================== RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mh,v retrieving revision 1.3 diff -c -r1.3 nbsdelf.mh *** nbsdelf.mh 2000/10/24 20:05:35 1.3 --- nbsdelf.mh 2000/11/09 22:42:17 *************** *** 1,6 **** # Host: Intel 386 running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \ ! i386nbsd-nat.o solib.o solib-svr4.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsdelf.h --- 1,5 ---- # Host: Intel 386 running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386nbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsdelf.h Index: config/i386/nbsdelf.mt =================================================================== RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mt,v retrieving revision 1.1 diff -c -r1.1 nbsdelf.mt *** nbsdelf.mt 2000/06/02 23:15:28 1.1 --- nbsdelf.mt 2000/11/09 22:42:17 *************** *** 1,5 **** # Target: Intel 386 running NetBSD ! TDEPFILES= i386-tdep.o i387-tdep.o TM_FILE= tm-nbsdelf.h GDBSERVER_DEPFILES= low-nbsd.o --- 1,5 ---- # Target: Intel 386 running NetBSD ! TDEPFILES= i386-tdep.o i387-tdep.o solib.o solib-svr4.o TM_FILE= tm-nbsdelf.h GDBSERVER_DEPFILES= low-nbsd.o Index: config/m68k/nbsd.mh =================================================================== RCS file: /cvs/src/src/gdb/config/m68k/nbsd.mh,v retrieving revision 1.4 diff -c -r1.4 nbsd.mh *** nbsd.mh 2000/10/24 20:05:35 1.4 --- nbsd.mh 2000/11/09 22:42:17 *************** *** 1,6 **** # Host: Motorola m68k running NetBSD XDEPFILES= ! NATDEPFILES= infptrace.o inftarg.o fork-child.o corelow.o \ ! m68knbsd-nat.o solib.o solib-svr4.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h --- 1,5 ---- # Host: Motorola m68k running NetBSD XDEPFILES= ! NATDEPFILES= infptrace.o inftarg.o fork-child.o corelow.o m68knbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h Index: config/m68k/nbsd.mt =================================================================== RCS file: /cvs/src/src/gdb/config/m68k/nbsd.mt,v retrieving revision 1.2 diff -c -r1.2 nbsd.mt *** nbsd.mt 2000/05/24 04:16:27 1.2 --- nbsd.mt 2000/11/09 22:42:17 *************** *** 1,3 **** # Target: Motorola m68k running NetBSD ! TDEPFILES= m68k-tdep.o TM_FILE= tm-nbsd.h --- 1,3 ---- # Target: Motorola m68k running NetBSD ! TDEPFILES= m68k-tdep.o solib.o solib-svr4.o TM_FILE= tm-nbsd.h Index: config/ns32k/nbsd.mh =================================================================== RCS file: /cvs/src/src/gdb/config/ns32k/nbsd.mh,v retrieving revision 1.4 diff -c -r1.4 nbsd.mh *** nbsd.mh 2000/10/24 20:05:36 1.4 --- nbsd.mh 2000/11/09 22:42:17 *************** *** 1,6 **** # Host: PC532 running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \ ! ns32knbsd-nat.o solib.o solib-svr4.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h --- 1,5 ---- # Host: PC532 running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o ns32knbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h Index: config/ns32k/nbsd.mt =================================================================== RCS file: /cvs/src/src/gdb/config/ns32k/nbsd.mt,v retrieving revision 1.2 diff -c -r1.2 nbsd.mt *** nbsd.mt 2000/05/24 04:16:27 1.2 --- nbsd.mt 2000/11/09 22:42:17 *************** *** 1,3 **** # Target: PC532 running NetBSD ! TDEPFILES= ns32k-tdep.o TM_FILE= tm-nbsd.h --- 1,3 ---- # Target: PC532 running NetBSD ! TDEPFILES= ns32k-tdep.o solib.o solib-svr4.o TM_FILE= tm-nbsd.h Index: config/powerpc/nbsd.mh =================================================================== RCS file: /cvs/src/src/gdb/config/powerpc/nbsd.mh,v retrieving revision 1.3 diff -c -r1.3 nbsd.mh *** nbsd.mh 2000/10/24 20:05:36 1.3 --- nbsd.mh 2000/11/09 22:42:17 *************** *** 1,5 **** # Host: PowerPC, running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o solib.o solib-svr4.o ppcnbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h --- 1,5 ---- # Host: PowerPC, running NetBSD XDEPFILES= ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o ppcnbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h Index: config/powerpc/nbsd.mt =================================================================== RCS file: /cvs/src/src/gdb/config/powerpc/nbsd.mt,v retrieving revision 1.3 diff -c -r1.3 nbsd.mt *** nbsd.mt 2000/07/31 20:56:43 1.3 --- nbsd.mt 2000/11/09 22:42:17 *************** *** 1,5 **** # Target: PowerPC, running NetBSD ! TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o TM_FILE= tm-nbsd.h GDBSERVER_DEPFILES= low-nbsd.o --- 1,5 ---- # Target: PowerPC, running NetBSD ! TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o solib.o solib-svr4.o TM_FILE= tm-nbsd.h GDBSERVER_DEPFILES= low-nbsd.o Index: config/sparc/nbsd.mh =================================================================== RCS file: /cvs/src/src/gdb/config/sparc/nbsd.mh,v retrieving revision 1.3 diff -c -r1.3 nbsd.mh *** nbsd.mh 2000/10/24 20:05:36 1.3 --- nbsd.mh 2000/11/09 22:42:17 *************** *** 2,6 **** XDEPFILES= XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o solib.o solib-svr4.o HOST_IPC=-DBSD_IPC --- 2,6 ---- XDEPFILES= XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o HOST_IPC=-DBSD_IPC Index: config/sparc/nbsd.mt =================================================================== RCS file: /cvs/src/src/gdb/config/sparc/nbsd.mt,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 nbsd.mt *** nbsd.mt 1999/12/14 01:05:42 1.1.1.2 --- nbsd.mt 2000/11/09 22:42:17 *************** *** 1,3 **** # Target: Sun 4 or Sparcstation, running NetBSD ! TDEPFILES= sparc-tdep.o TM_FILE= tm-nbsd.h --- 1,3 ---- # Target: Sun 4 or Sparcstation, running NetBSD ! TDEPFILES= sparc-tdep.o solib.o solib-svr4.o TM_FILE= tm-nbsd.h Index: config/sparc/nbsdelf.mh =================================================================== RCS file: /cvs/src/src/gdb/config/sparc/nbsdelf.mh,v retrieving revision 1.3 diff -c -r1.3 nbsdelf.mh *** nbsdelf.mh 2000/10/24 20:05:36 1.3 --- nbsdelf.mh 2000/11/09 22:42:17 *************** *** 2,6 **** XDEPFILES= XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsdelf.h ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o solib.o solib-svr4.o HOST_IPC=-DBSD_IPC --- 2,6 ---- XDEPFILES= XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsdelf.h ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o HOST_IPC=-DBSD_IPC -- J.T. Conklin RedBack Networks >From fnasser@cygnus.com Thu Nov 09 15:36:00 2000 From: Fernando Nasser To: gdb-patches@sources.redhat.com Subject: Fixed 2 testsuite regressions Date: Thu, 09 Nov 2000 15:36:00 -0000 Message-id: <3A0B34F8.A8155249@cygnus.com> X-SW-Source: 2000-11/msg00120.html Content-length: 5163 Just a quick fix to the pattern expected. There was no real problem. * gdb.c++/templates.exp (test_template_breakpoints): Change Britsh spelling "cancelled" to U.S. spelling "canceled" to match changes made to gdb. * gdb.c++/ovldbreak.exp: Ditto. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/ovldbreak.exp,v retrieving revision 1.1.1.5 diff -c -p -r1.1.1.5 ovldbreak.exp *** ovldbreak.exp 2000/02/05 07:30:00 1.1.1.5 --- ovldbreak.exp 2000/11/09 23:22:58 *************** gdb_expect { *** 456,471 **** -re "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::overload1arg\\(double\\) at.*$srcfile:121\r\n\\\[3\\\] foo::overload1arg\\(float\\) at.*$srcfile:120\r\n\\\[4\\\] foo::overload1arg\\(unsigned long\\) at.*$srcfile:119\r\n\\\[5\\\] foo::overload1arg\\(long\\) at.*$srcfile:118\r\n\\\[6\\\] foo::overload1arg\\(unsigned int\\) at.*$srcfile:117\r\n\\\[7\\\] foo::overload1arg\\(int\\) at.*$srcfile:116\r\n\\\[8\\\] foo::overload1arg\\(unsigned short\\) at.*$srcfile:115\r\n\\\[9\\\] foo::overload1arg\\(short\\) at.*$srcfile:114\r\n\\\[10\\\] foo::overload1arg\\(unsigned char\\) at.*$srcfile:113\r\n\\\[11\\\] foo::overload1arg\\(signed char\\) at.*$srcfile:112\r\n\\\[12\\\] foo::overload1arg\\(char\\) at.*$srcfile:111\r\n\\\[13\\\] foo::overload1arg\\(void\\) at.*$srcfile:110\r\n> $" { send_gdb "0\n" gdb_expect { ! -re "cancelled\r\n$gdb_prompt $" { ! pass "set bp cancelled" } -re ".*$gdb_prompt $" { ! fail "set bp cancelled wrong bp reply" } timeout { ! fail "(timeout)set bp cancelled wrong bp reply" } } } ! -re ".*$gdb_prompt $" { fail "set bp cancelled(wrong menu)" } ! timeout { fail "(timeout)set bp cancelled(wrong menu)" } } --- 456,471 ---- -re "\\\[0\\\] cancel\r\n\\\[1\\\] all\r\n\\\[2\\\] foo::overload1arg\\(double\\) at.*$srcfile:121\r\n\\\[3\\\] foo::overload1arg\\(float\\) at.*$srcfile:120\r\n\\\[4\\\] foo::overload1arg\\(unsigned long\\) at.*$srcfile:119\r\n\\\[5\\\] foo::overload1arg\\(long\\) at.*$srcfile:118\r\n\\\[6\\\] foo::overload1arg\\(unsigned int\\) at.*$srcfile:117\r\n\\\[7\\\] foo::overload1arg\\(int\\) at.*$srcfile:116\r\n\\\[8\\\] foo::overload1arg\\(unsigned short\\) at.*$srcfile:115\r\n\\\[9\\\] foo::overload1arg\\(short\\) at.*$srcfile:114\r\n\\\[10\\\] foo::overload1arg\\(unsigned char\\) at.*$srcfile:113\r\n\\\[11\\\] foo::overload1arg\\(signed char\\) at.*$srcfile:112\r\n\\\[12\\\] foo::overload1arg\\(char\\) at.*$srcfile:111\r\n\\\[13\\\] foo::overload1arg\\(void\\) at.*$srcfile:110\r\n> $" { send_gdb "0\n" gdb_expect { ! -re "canceled\r\n$gdb_prompt $" { ! pass "set bp canceled" } -re ".*$gdb_prompt $" { ! fail "set bp canceled wrong bp reply" } timeout { ! fail "(timeout)set bp canceled wrong bp reply" } } } ! -re ".*$gdb_prompt $" { fail "set bp canceled(wrong menu)" } ! timeout { fail "(timeout)set bp canceled(wrong menu)" } } Index: templates.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/templates.exp,v retrieving revision 1.2 diff -c -p -r1.2 templates.exp *** templates.exp 2000/06/05 20:47:28 1.2 --- templates.exp 2000/11/09 23:22:58 *************** proc test_template_breakpoints {} { *** 105,116 **** gdb_expect { -re "0. cancel.*\[\r\n\]*.1. all.*\[\r\n\]*.2. T5::T5\\(int\\) at .*\[\r\n\]*.3. T5::T5\\(T5 const &\\) at .*\[\r\n\]*> $" { gdb_test "0" \ ! "cancelled" \ "constructor breakpoint (obsolete format!)" } -re ".0. cancel\[\r\n\]*.1. all\[\r\n\]*.2. T5::T5\\(T5 const &\\) at .*templates.cc:.*\[\r\n\]*.3. T5::T5\\(int\\) at .*templates.cc:.*\[\r\n\]*> $" { gdb_test "0" \ ! "cancelled" \ "constructor breakpoint" } -re ".*$gdb_prompt $" { fail "constructor breakpoint" } --- 105,116 ---- gdb_expect { -re "0. cancel.*\[\r\n\]*.1. all.*\[\r\n\]*.2. T5::T5\\(int\\) at .*\[\r\n\]*.3. T5::T5\\(T5 const &\\) at .*\[\r\n\]*> $" { gdb_test "0" \ ! "canceled" \ "constructor breakpoint (obsolete format!)" } -re ".0. cancel\[\r\n\]*.1. all\[\r\n\]*.2. T5::T5\\(T5 const &\\) at .*templates.cc:.*\[\r\n\]*.3. T5::T5\\(int\\) at .*templates.cc:.*\[\r\n\]*> $" { gdb_test "0" \ ! "canceled" \ "constructor breakpoint" } -re ".*$gdb_prompt $" { fail "constructor breakpoint" } >From kevinb@cygnus.com Thu Nov 09 17:14:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Cc: Jim Blandy , Ulrich Drepper Subject: Re: [PATCH RFA] solib-svr4.c patch for dynamic executables Date: Thu, 09 Nov 2000 17:14:00 -0000 Message-id: <1001110011408.ZM28325@ocotillo.lan> References: <1001104012305.ZM6714@ocotillo.lan> <1001108013427.ZM19910@ocotillo.lan> X-SW-Source: 2000-11/msg00121.html Content-length: 2562 On Nov 7, 6:34pm, Kevin Buettner wrote: > I withdraw my former patch in favor of the one below. > > Changes based on a patch from Ulrich Drepper: > * solib-svr4.c (svr4_relocate_main_executable): New function. > (svr4_solib_create_inferior_hook): Call > svr4_relocate_main_executable. Committed. I added the additional test that Jim Blandy asked for which makes sure that the executable is dynamic. Here are what the comments and the code for the test look like: /* Decide if the objfile needs to be relocated. As indicated above, we will only be here when execution is stopped at the beginning of the program. Relocation is necessary if the address at which we are presently stopped differs from the start address stored in the executable AND there's no interpreter section. The condition regarding the interpreter section is very important because if there *is* an interpreter section, execution will begin there instead. When there is an interpreter section, the start address is (presumably) used by the interpreter at some point to start execution of the program. If there is an interpreter, it is normal for it to be set to an arbitrary address at the outset. The job of finding it is handled in enable_break(). So, to summarize, relocations are necessary when there is no interpreter section and the start address obtained from the executable is different from the address at which GDB is currently stopped. [ The astute reader will note that we also test to make sure that the executable in question has the DYNAMIC flag set. It is my opinion that this test is unnecessary (undesirable even). It was added to avoid inadvertent relocation of an executable whose e_type member in the ELF header is not ET_DYN. There may be a time in the future when it is desirable to do relocations on other types of files as well in which case this condition should either be removed or modified to accomodate the new file type. (E.g, an ET_EXEC executable which has been built to be position-independent could safely be relocated by the OS if desired. It is true that this violates the ABI, but the ABI has been known to be bent from time to time.) - Kevin, Nov 2000. ] */ interp_sect = bfd_get_section_by_name (exec_bfd, ".interp"); if (interp_sect == NULL && (bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0 && bfd_get_start_address (exec_bfd) != pc)