From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: eliz@is.elta.co.il Cc: jimb@zwingli.cygnus.com, kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003192248.e2JMm1H00626@delius.kettenis.local> References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <200003182227.RAA07058@indy.delorie.com> X-SW-Source: 2000-q1/msg00790.html Date: Sat, 18 Mar 2000 17:27:44 -0500 (EST) From: Eli Zaretskii > *** gdb/Makefile.in 2000/03/16 10:23:38 1.13 > --- gdb/Makefile.in 2000/03/17 19:59:40 > *************** > *** 1063,1068 **** > --- 1063,1069 ---- > i386-tdep.c i386b-nat.c i386mach-nat.c i386v-nat.c i386-linux-nat.c \ > i386aix-nat.c i386m3-nat.c i386v4-nat.c i386ly-tdep.c \ > i387-tdep.c \ > + i386-linux-tdep.c \ > i960-tdep.c \ > infptrace.c inftarg.c irix4-nat.c irix5-nat.c isi-xdep.c \ > lynx-nat.c m3-nat.c \ I see you already added the new file. Sigh... Is it possible to find a different name for it, one which won't clash with i386-linux-nat.c? How about i386linux-tdep.c, for example? Yuck, that's ugly! Is it really important that these Linux-specific files are correctly extracted on MS-DOS? I believe your argument was about buggy tar programs floating around, but I don't think it is too much too ask people to fix their tar before trying to build GDB. Mark >From fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: jtc@redback.com Cc: GDB Patches Subject: Re: Deprecating commands; Was: RFC: patch for ... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AAFCB4.EFC20163@cygnus.com> References: <38AA23AF.34D2C08B@cygnus.com> <38AAE434.E3B21500@cygnus.com> <5memad2bsw.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00200.html Content-length: 1745 "J.T. Conklin" wrote: > > >>>>> "Fernando" == Fernando Nasser writes: > Fernando> Talking about "bad" commands, what can be worse that the > Fernando> "set" overloading? It should only work for gdb control > Fernando> switches. The "set var" should be name "assign". But who > Fernando> dares to change this after 15+ years... > > If we were to have a different command for setting variables, I'd pick > "write" over "assign". However I see this in much the same way as the > BASIC "LET" keyword --- a useless bit of syntactic sugar. I'd prefer > being able to set program variables directly: > > (gdb) print x > $1 = 3 > (gdb) x = 4 > Sure, but on the other hand not having the "set"/"let"/"assign"/"write" or whatever keyord starts to impose restrictions on variable names. You end up with a reserved keyword list that is the union of all languages supported by gdb. > but I suspect that would require a major overhaul of the command > parser. > Yes, it probably would. > Another issue is that "set" is used to assign convienence variables > and GDB's internal variables. I see some merit in actually merging > these so that scripts can access the values. There are some issues > that may make it difficult to do. For example, many set commands do > extra error checking that simply setting a convienence variable would > not; GBD's scripting language has only a global identifier namespace; > etc. Nevertheless, I'd love to be able to do this. > Good points. -- 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 eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: kettenis@wins.uva.nl Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: DJGPP build and cleanup Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002241118.GAA19392@indy.delorie.com> References: <200002232229.RAA18809@indy.delorie.com> <200002232247.e1NMljJ28359@delius.kettenis.local> X-SW-Source: 2000-q1/msg00357.html Content-length: 2026 > From: Mark Kettenis > > Date: Wed, 23 Feb 2000 17:29:16 -0500 (EST) > From: Eli Zaretskii > > The change to i386-tdep.c should probably be approved by someone (I > cannot figure out from MAINTAINERS who's responsible for i386 > targets). > > Youd didn't include the changes to i386-tdep.c :-(. I erroneously appended them to the other set of patches I sent yesterday. I attach it below again. > The point is that if you look at the GCC configuration files, you'll > see that returning FP values in the FP registers is the default for > most (probably all) i386 targets. So I think this should be the > default in GDB too. I didn't know that this was the case, but if it is so, I agree that returning FP values in registers should be the default. 2000-02-23 Eli Zaretskii * i386-tdep.c (i386_extract_return_value) [I386_AIX_TARGET || I386_GNULINUX_TARGET]: Add I386_DJGPP_TARGET to the list of targets which return FP values in FP registers. --- gdb/i386-tdep.c~0 Tue Oct 19 02:46:36 1999 +++ gdb/i386-tdep.c Wed Feb 23 12:17:20 2000 @@ -702,9 +702,9 @@ i386_extract_return_value (type, regbuf, char regbuf[REGISTER_BYTES]; char *valbuf; { - /* On AIX and i386 GNU/Linux, floating point values are returned in - floating point registers. */ -#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) + /* On AIX, i386 GNU/Linux and DJGPP, floating point values are + returned in floating point registers. */ +#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET) if (TYPE_CODE_FLT == TYPE_CODE (type)) { double d; @@ -720,7 +720,7 @@ i386_extract_return_value (type, regbuf, store_floating (valbuf, TYPE_LENGTH (type), d); } else -#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET*/ +#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */ { #if defined(LOW_RETURN_REGNUM) int len = TYPE_LENGTH (type); >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: Peter.Schauer@regent.e-technik.tu-muenchen.de Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: breakpoint.c: Minor output fixes for hardware watchpoints Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091337.IAA19948@indy.delorie.com> References: <200003072114.WAA26280@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00618.html Content-length: 884 > During implementation of hardware watchpoints on Solaris, I noticed the > following inconsistencies in breakpoint.c output between software and > hardware breakpoints. Both problems confirmed on x86 using the DJGPP native version. Actually, these two problems were on my todo list since last summer, but since they are merely annoyances, they got pushed back ;-). > Here is a patch for both problems: > > 2000-03-07 Peter Schauer > > * breakpoint.c (insert_breakpoints, do_enable_breakpoint): Reselect > the saved frame silently after frame selection for watchpoint > evaluation. > (insert_breakpoints): Add missing space in `Hardware watchpoint > deleted' message. Do not reinsert hardware watchpoint if it is > already marked for deletion at next stop. Both problems are gone with these patches in the DJGPP version. Thanks! >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Fernando Nasser Cc: Scott Bambrough , gdb-patches@sourceware.cygnus.com, jingham@cygnus.com Subject: Re: Patch for arm_push_arguments Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CEDC1A.7D997EF3@cygnus.com> References: <38CE9C8B.3EC5B7F1@netwinder.org> <38CEA1FF.CEA9553@cygnus.com> X-SW-Source: 2000-q1/msg00699.html Content-length: 972 Fernando Nasser wrote: > > Scott, > > I have to try it on a few targets, so I need a few days. I will try to run all the tests this week though. > > Thanks for doing this. > > Fernando > > Scott Bambrough wrote: > > > > Hi guys, > > > > * arm-tdep.c (arm_push_arguments): Correctly code for converting a > > float argument from host format to a target double when preparing the > > call frame for a function. > > > > This works for me. Can you try it out. If it works, let me know and I'll check > > it in. > > > > Scott > > Scott, To expand on what I suspect Fernando is doing, he probably has built a ``--target=arm-elf'' tool-chain (compiler, linker, debugger) and is then testing it a dejagnu entry like: { "arm-*elf" } { set target_list "arm-sim/-mlittle-endian" } (along with a few extra's for remote boards). This checks both big and little endian targets without any need to own real hardware. enjoy, Andrew >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: dan@cgsoftware.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] Demangled minsym hash table broken Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E2A65B.7C32@cygnus.com> References: X-SW-Source: 2000-q1/msg01116.html Content-length: 186 Daniel Berlin wrote: > So up until now, the demangled symbol table was never working, as i > had suspected. Well, that is, since the addition of the hash table (I'm sure you meant)... >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: shebs@apple.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] testsuite changes needed for AIX 4.3 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000216021706.ZM2429@ocotillo.lan> References: <1000215230816.ZM2175@ocotillo.lan> <38A9E4F9.514007E1@apple.com> X-SW-Source: 2000-q1/msg00165.html Content-length: 1514 On Feb 15, 3:44pm, Stan Shebs wrote: > Kevin Buettner wrote: > > > > I hereby reqest approval for committing the following changes: > > > > * gdb.base/pointers.c (usevar): New function. > > (main): Make sure that global variables v_int_pointer2, rptr, > > and y are all referenced someplace in the program by calling > > usevar() on them. [Some linkers delete symbols which are > > never referenced. The space remains, but there's no way to > > get a (symbolic) handle on the variable from the debugger.] > > > > * gdb.base/scope.exp: For powerpc-*-*, xfail the same tests > > that rs6000-*-* does. > > This looks reasonable to me, with the same question as Mark Kettenis > raises: are the xfails unconditional because the tests fail whether > xlc or gcc is used as the compiler? If they pass with xlc, then you > need to test gcc_compiled. Okay. As soon as I get the rest of my patches from the branch I was working on merged in, I was going to do a build from sourceware. I'll test with xlc then. (The machine that I had been working on didn't have xlc on it, or if it did, I couldn't find it.) Also, I'd appreciate it if someone could explain to me why these xfails are necessary. (I haven't looked hard at the problem; I just noticed that these tests were xfailed for rs6000, and I was getting FAILs on powerpc, so it seemed reasonable to xfail them for powerpc too.) Kevin -- Kevin Buettner kev@primenet.com, kevinb@redhat.com >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jimmy Guo Cc: Michael Snyder , John David Anglin , gdb-patches@sourceware.cygnus.com Subject: Re: Initialization of hpux_threads Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D7F9C4.ECF7E17F@cygnus.com> References: X-SW-Source: 2000-q1/msg00879.html Content-length: 1706 Jimmy Guo wrote: > > On Fri, 17 Mar 2000, Michael Snyder wrote: > > >John David Anglin wrote: > >> > >> Thu Mar 16 16:49:27 EST 2000 John David Anglin > >> > >> * configure.in: Don't call _initialize_hpux_thread twice. > >> * configure: Regenerated. > >> > >> --- configure.in.orig Mon Mar 6 18:30:12 2000 > >> +++ configure.in Thu Mar 16 14:22:26 2000 > >> @@ -330,7 +330,6 @@ > >> AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT) > >> CONFIG_OBS="${CONFIG_OJS} hpux-thread.o" > >> CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c" > >> - CONFIG_INITS="${CONFIG_INITS} hpux-thread.c" > >> else > >> AC_MSG_RESULT(no (suppressed because you are not using GCC)) > >> fi > > > >If someone from HP will approve this, I will check it in... > > > > Michael Snyder > > This looks fine. Just an observation: > CONFIG_OBS is part of DEPFILES, which is part of COMMON_OBS, which is > part of OBS, which is part of INITFILES. It looks like all three usages > of CONFIG_INITS in configure.in can be removed. Maybe you can just > remove CONFIG_INITS altogether in configure.in and Makefile.in. Since > OBS file list is already looked at by init.c rule, it really makes no > sense to maintain a CONFIG_INITS file list. No. CONFIG_INITS was added because things get complicated when adding sub-directory files (eg MI) that contain _initialize_*() functions. The mistake was to assume that it was needed in all (rather than special) cases. By doing this the MI avoided the need to add any nasty initialization hooks to main() - unlike tui, MPW, and GDBTK. Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Stan Shebs Cc: Michael Snyder , gdb-patches@sourceware.cygnus.com Subject: Re: gdb.texinfo broken? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D7FDD1.D54DE1D8@cygnus.com> References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00882.html Content-length: 325 "J.T. Conklin" wrote: > It looks like the changes to the directory entry require the latest > makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed, > makeinfo from texinfo-4.0 works. >From memory, the possibility of requiring texinfo 4.0 as part of building GDB 5 was considered and rejected :-( oops, Andrew >From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: store_floating() and arm-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C917C1.3E6E2C19@netwinder.org> References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org> <38C7F23D.61AF@cygnus.com> X-SW-Source: 2000-q1/msg00642.html Content-length: 1429 > Scott Bambrough wrote: > > > > I've been running tests on the ARM Linux target on a NetWinder regularly. The > > results of the testsuite follow. Most of the problems are due to no > > linuxthreads support and problems stepping in/out or backtracing in signal > > handlers. I'll work at implementing support for these over time. I was hoping > > to port the x86 work, but just haven't had the time. > Michael Snyder wrote: > > Hmm, the new thread_db module should be pretty > target-independent (correct me if I'm wrong). Ok. I attempted to put the linuxthreads support in last night. It was relatively painless, but I have reached a stumbling block with glibc 2.1.2. In gdb_proc_service.h there are the following two definitions: #ifndef HAVE_PRGREGSET_T typedef gregset_t prgregset_t; /* BOGUS BOGUS BOGUS */ #endif #ifndef HAVE_PRFPREGSET_T typedef fpregset_t prfpregset_t; /* BOGUS BOGUS BOGUS */ #endif The BOGUS comments are accurate. Neither gregset_t or fpregset_t are defined in . prgregset_t and prfpregset_t are also used in gdb_threads_db.h as well without checking the defines from config.h. I'm trying this on 2.1.3 ATM, but for the most part, the installed base of users is using 2.1.2 on ARM Linux. Any thoughts on how I could get around this? Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: [PATCH] gdbarch cleanups part 1 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E2E686.2227D8F9@cygnus.com> X-SW-Source: 2000-q1/msg01122.html Content-length: 5983 FYI, I committed the attatched cleanups. Andrew  Thu Mar 30 12:09:50 2000 Andrew Cagney * gdbarch.h, gdbarch.c: Re-indent. Remove FIXMEs. * gdbarch.sh: Re-sync with gdbarch.[hc]. Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.5 diff -p -r1.5 gdbarch.sh *** gdbarch.sh 2000/03/21 20:40:43 1.5 --- gdbarch.sh 2000/03/30 05:31:15 *************** *** 1,7 **** #!/usr/local/bin/bash # Architecture commands for GDB, the GNU debugger. ! # Copyright 1998-1999 Free Software Foundation, Inc. # # This file is part of GDB. # --- 1,7 ---- #!/usr/local/bin/bash # Architecture commands for GDB, the GNU debugger. ! # Copyright 1998-2000 Free Software Foundation, Inc. # # This file is part of GDB. # *************** *** 19,24 **** --- 19,40 ---- # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + compare_new () + { + file=$1 + if ! test -r ${file} + then + echo "${file} missing? cp new-${file} ${file}" 1>&2 + elif diff -c ${file} new-${file} + then + echo "${file} unchanged" 1>&2 + else + echo "${file} has changed? cp new-${file} ${file}" 1>&2 + fi + } + + + # Format of the input table read="class level macro returntype function formal actual attrib default init invalid_p fmt print print_p description" # dump out/verify the doco *************** fi *** 259,264 **** --- 275,282 ---- copyright () { cat <&2 #../move-if-change new-gdbarch.h gdbarch.h ! if ! test -r gdbarch.h ! then ! echo "gdbarch.h missing? cp new-gdbarch.h gdbarch.h" 1>&2 ! elif diff -c gdbarch.h new-gdbarch.h ! then ! echo "gdbarch.h unchanged" 1>&2 ! else ! echo "gdbarch.h has changed? cp new-gdbarch.h gdbarch.h" 1>&2 ! fi # --- 758,764 ---- EOF exec 1>&2 #../move-if-change new-gdbarch.h gdbarch.h ! compare_new gdbarch.h # *************** struct gdbarch_tdep * *** 1076,1082 **** gdbarch_tdep (struct gdbarch *gdbarch) { if (gdbarch_debug >= 2) - /* FIXME: gdb_std??? */ fprintf_unfiltered (gdb_stdlog, "gdbarch_tdep called\n"); return gdbarch->tdep; } --- 1084,1089 ---- *************** do *** 1098,1104 **** echo " if (gdbarch->${function} == 0)" echo " internal_error (\"gdbarch: gdbarch_${function} invalid\");" echo " if (gdbarch_debug >= 2)" - echo " /* FIXME: gdb_std??? */" echo " fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");" test "${actual}" = "-" && actual="" if [ "${returntype}" = "void" ] --- 1105,1110 ---- *************** do *** 1131,1137 **** echo " internal_error (\"gdbarch: gdbarch_${function} invalid\");" fi echo " if (gdbarch_debug >= 2)" - echo " /* FIXME: gdb_std??? */" echo " fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");" echo " return gdbarch->${function};" echo "}" --- 1137,1142 ---- *************** do *** 1149,1155 **** echo "gdbarch_${function} (struct gdbarch *gdbarch)" echo "{" echo " if (gdbarch_debug >= 2)" - echo " /* FIXME: gdb_std??? */" echo " fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");" echo " return gdbarch->${function};" echo "}" --- 1154,1159 ---- *************** extern void _initialize_gdbarch (void); *** 1965,1970 **** --- 1969,1976 ---- void _initialize_gdbarch () { + struct cmd_list_element *c; + add_prefix_cmd ("endian", class_support, set_endian, "Set endianness of target.", &endianlist, "set endian ", 0, &setlist); *************** _initialize_gdbarch () *** 1991,2015 **** tm_print_insn_info.memory_error_func = dis_asm_memory_error; tm_print_insn_info.print_address_func = dis_asm_print_address; ! add_show_from_set (add_set_cmd ("archdebug", class_maintenance, var_zinteger, (char *)&gdbarch_debug, "Set architecture debugging.\n\\ ! When non-zero, architecture debugging is enabled.", &setlist), ! &showlist); } EOF # close things off exec 1>&2 #../move-if-change new-gdbarch.c gdbarch.c ! if ! test -r gdbarch.c ! then ! echo "gdbarch.c missing? cp new-gdbarch.c gdbarch.c" 1>&2 ! elif diff -c gdbarch.c new-gdbarch.c ! then ! echo "gdbarch.c unchanged" 1>&2 ! else ! echo "gdbarch.c has changed? cp new-gdbarch.c gdbarch.c" 1>&2 ! fi --- 1997,2022 ---- tm_print_insn_info.memory_error_func = dis_asm_memory_error; tm_print_insn_info.print_address_func = dis_asm_print_address; ! add_show_from_set (add_set_cmd ("arch", class_maintenance, var_zinteger, (char *)&gdbarch_debug, "Set architecture debugging.\n\\ ! When non-zero, architecture debugging is enabled.", &setdebuglist), ! &showdebuglist); ! c = add_set_cmd ("archdebug", ! class_maintenance, ! var_zinteger, ! (char *)&gdbarch_debug, ! "Set architecture debugging.\n\\ ! When non-zero, architecture debugging is enabled.", &setlist); ! ! deprecate_cmd (c, "set debug arch"); ! deprecate_cmd (add_show_from_set (c, &showlist), "show debug arch"); } EOF # close things off exec 1>&2 #../move-if-change new-gdbarch.c gdbarch.c ! compare_new gdbarch.c >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Cc: cagney@cygnus.com, fnasser@cygnus.com Subject: [PATCH]: swat a warning in cli-out.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003240110.RAA21711@seadog.cygnus.com> X-SW-Source: 2000-q1/msg00960.html Content-length: 1137 This eliminates a warning on 64-bit solaris. 2000-03-23 Michael Snyder * cli-out.h: include gdb_string.h to avoid compiler warnings. Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.170 diff -c -r1.170 ChangeLog *** ChangeLog 2000/03/23 23:43:19 1.170 --- ChangeLog 2000/03/24 01:08:15 *************** *** 1,3 **** --- 1,7 ---- + 2000-03-23 Michael Snyder + + * cli-out.h: include gdb_string.h to avoid compiler warnings. + 2000-03-23 Fernando Nasser From David Whedon Index: cli-out.c =================================================================== RCS file: /cvs/src/src/gdb/cli-out.c,v retrieving revision 1.2 diff -c -r1.2 cli-out.c *** cli-out.c 2000/02/20 18:23:31 1.2 --- cli-out.c 2000/03/24 01:08:15 *************** *** 23,28 **** --- 23,29 ---- #include "defs.h" #include "ui-out.h" #include "cli-out.h" + #include "gdb_string.h" /* Convenience macro for allocting typesafe memory. */ >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: gdb-patches@sourceware.cygnus.com Subject: PATCH corefiles reading on alpha-linux Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14526.63171.337788.889969@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00461.html Content-length: 1733 gdb/config/alpha/alpha-linux.mh lists core-regset.o as one of the NATDEPFILES. This causes _initialize_core_regset() to be called, and this in turn calls add_core_fns with bfd_target_elf_flavour. Later on, _initialize_core_alpha() adds another core function structure with the same flavour. When a core file is loaded, this causes a warning to be printed, because both function sets match the expected bfd flavour. I am going to check this in. OK? Elena Index: alpha-linux.mh =================================================================== RCS file: /cvs/src/src/gdb/config/alpha/alpha-linux.mh,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 alpha-linux.mh *** alpha-linux.mh 1999/12/22 21:45:12 1.1.1.3 --- alpha-linux.mh 2000/03/02 23:15:59 *************** *** 2,8 **** XDEPFILES= ser-tcp.o XM_FILE= xm-alphalinux.h NAT_FILE= nm-linux.h ! NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \ fork-child.o solib.o linux-thread.o lin-thread.o LOADLIBES = -ldl -rdynamic --- 2,8 ---- XDEPFILES= ser-tcp.o XM_FILE= xm-alphalinux.h NAT_FILE= nm-linux.h ! NATDEPFILES= infptrace.o inftarg.o corelow.o alpha-nat.o \ fork-child.o solib.o linux-thread.o lin-thread.o LOADLIBES = -ldl -rdynamic Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.95 diff -c -r1.95 ChangeLog *** ChangeLog 2000/03/02 15:44:27 1.95 --- ChangeLog 2000/03/02 23:17:32 *************** *** 1,3 **** --- 1,8 ---- + 2000-03-02 Elena Zannoni + + * config/alpha/alpha-linux.mh: Remove core-regset.o fron the + NATDEPFILES list. +