From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch_free Date: Mon, 28 Feb 2000 17:03:00 -0000 Message-id: <38BB1A9A.61A680AA@cygnus.com> References: <200002282302.SAA13215@zwingli.cygnus.com> X-SW-Source: 2000-02/msg00060.html Jim Blandy wrote: > > There are no uses for this yet, except in some code that's not ready > for release yet. > > 2000-02-28 Jim Blandy > > * gdbarch.sh: Emit a definition and declaration for gdbarch_free, > a companion to gdbarch_alloc, which allows a gdbarch init function > to free partially-built gdbarch structures. > * gdbarch.c, gdbarch.h: Regenerated. Jim, Can you expand a little. >From memory, I figured that if an _initialize* function failed to create a gdbarch the process was somewhat hosed and calling internal_error() was probably the best thing to do. Andrew >From ac131313@cygnus.com Mon Feb 28 18:08:00 2000 From: Andrew Cagney To: GDB Patches Subject: Please ``withdraw'' patches Date: Mon, 28 Feb 2000 18:08:00 -0000 Message-id: <38BB29FF.2467FCE@cygnus.com> X-SW-Source: 2000-02/msg00061.html Content-length: 449 Hello, I've just spent an hour going over a patch (yes I'm working through a long backlog) only to then find a later submission by the same author supersedes the earlier posting. If people withdraw or re-submit patches, could they please to a follow up to the original posting making it clear that that submission was withdrawn. enjoy, Andrew (Hopefully a patch tracking system will help with this problem (although it may not eliminate it)) >From ac131313@cygnus.com Mon Feb 28 18:23:00 2000 From: Andrew Cagney To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com, Elena Zannoni Subject: Re: RFA: Patch to blockframe.c, frame.h, arm-tdep.c and fr30-tdep.c (prologue cache) Date: Mon, 28 Feb 2000 18:23:00 -0000 Message-id: <38BB2D7D.4081A59B@cygnus.com> References: <38ACA4D6.993AFF74@cygnus.com> X-SW-Source: 2000-02/msg00062.html Content-length: 1412 Fernando Nasser wrote: > > I believe the following fixes a bug found by Elena. > > Fernando > > 2000-02-17 Fernando Nasser > > * blockframe.c (check_prologue_cache, save_prologue_cache, > flush_prologue_cache): Slightly improved version of a prologue > cache > used by some targets. Here there is a flush mechanism so we > never use > stale data. > * frame.h: Prototypes for the above functions. > * arm-tdep.c (check_prologue_cache, save_prologue_cache): > Deleted. > Moved (with changes) to blockframe.c. First a technical question: Does the code work with targets with EXTRA_FRAME_INFO and INIT_EXTRA_FRAME_INFO? I'm not sure if that should be saved or not? At a less technical level I also encountered the following problems: o The function flush_prologue_cache() is called as flush_prolog_cache(). As it stands, the patch won't compile. o the change to frame.h creates ``extern static ... PARAMS (())'' The PARAMS bit isn't necessary and I suspect the ``extern static'' was a cut/paste mistake. The header should also briefly explain what the interface is. o the file fr30-tdep.c was changed but the ChangeLog didn't mention it o btw your mail tool corrupted the patch (splitting several lines) o I'd recommend making the FI param to save_prologue_cache const. sorry, Andrew >From ac131313@cygnus.com Mon Feb 28 21:10:00 2000 From: Andrew Cagney To: Stephane Carrez Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2 Date: Mon, 28 Feb 2000 21:10:00 -0000 Message-id: <38BB5463.D6E5B75C@cygnus.com> References: <38B2F3D3.54CF0AF0@worldnet.fr> X-SW-Source: 2000-02/msg00063.html Content-length: 2194 Stephane Carrez wrote: > > Hi! > > The following patch fixes GDB dwarf-2 reader to support 16-bit address > targets. > > In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the > target address. We were using the bfd 'elf_size_info::arch_size' member. > This corresponds to the ELF file arch size, not the target address size. > I suggest to use 'bfd_arch_bits_per_address' which really corresponds to > what we need. > > Then, in 'read_address', we just have to read 2-bytes addresses. > > I've been using this fix for a while with the 68HC11 port. > > Can you integrate it? > > Thanks, > Stephane > > 2000-02-22 Stephane Carrez > > * dwarf2read.c (dwarf2_build_psymtabs_hard): Use > bfd_arch_bits_per_address to get the size of addresses. FYI, I've applied this bit: > (read_address): Read 16-bits addresses. As for the change: > - address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8; > + address_significant_size = bfd_arch_bits_per_address (abfd) / 8; I'm not so sure. Does bfd_arch_bits_per_address() return 16 while the elf data arch_size indicate something else (elf32 vs elf16?) I've attatched some references to when a similar problem was discussed for a 64 bit target with 32 bit ELF binaries. Jim? Andrew http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html Tue Feb 29 15:14:56 2000 Andrew Cagney From 2000-02-22 Stephane Carrez : * dwarf2read.c (read_address): Read 16-bits addresses. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.2 diff -p -r1.2 dwarf2read.c *** dwarf2read.c 2000/02/14 04:37:06 1.2 --- dwarf2read.c 2000/02/29 05:06:26 *************** read_address (abfd, buf) *** 3487,3492 **** --- 3487,3495 ---- switch (address_size) { + case 2: + retval = bfd_get_16 (abfd, (bfd_byte *) buf); + break; case 4: retval = bfd_get_32 (abfd, (bfd_byte *) buf); break; >From ac131313@cygnus.com Mon Feb 28 21:49:00 2000 From: Andrew Cagney To: tromey@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch: make "!" a command unconditionally Date: Mon, 28 Feb 2000 21:49:00 -0000 Message-id: <38BB5D9F.1A9BF1B3@cygnus.com> References: <87itz9cabi.fsf@cygnus.com> X-SW-Source: 2000-02/msg00064.html Content-length: 1214 Tom Tromey wrote: > > I'd like "!" to be an unconditional alias for "shell". > Here is a patch. > > 2000-02-28 Tom Tromey > > * command.c (_initialize_command): Make "!" alias > unconditionally. > > Tom > > Index: command.c > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/command.c,v > retrieving revision 1.65 > diff -u -r1.65 command.c > --- command.c 2000/02/09 08:53:11 1.65 > +++ command.c 2000/02/28 20:57:08 > @@ -1678,8 +1678,7 @@ > "Execute the rest of the line as a shell command. \n\ > With no arguments, run an inferior shell."); > > - if (xdb_commands) > - add_com_alias ("!", "shell", class_support, 0); > + add_com_alias ("!", "shell", class_support, 0); > > add_com ("make", class_support, make_command, > "Run the ``make'' program using the rest of the line as arguments."); >From memory this has been suggested before. The problem pointed out last time was that you need to specify: ``!'' I think there also may have been a debate over ``!'' as a shell escape vs ``!'' for history. (personally it didn't worry me). Fernando? Andrew >From ac131313@cygnus.com Mon Feb 28 22:25:00 2000 From: Andrew Cagney To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: Prologue cache fix Date: Mon, 28 Feb 2000 22:25:00 -0000 Message-id: <38BB65F6.44D991A2@cygnus.com> References: <38B4073E.281C4CE0@redhat.com> X-SW-Source: 2000-02/msg00065.html Content-length: 1434 Fernando Nasser wrote: > > This patch fixes a problem that happens when gdb reconnects to a > target. Targets that have a prologue cache must invalidate its contents > or they can assume wrong things based on stale data. I'm wondering when exactly this prologue_cache provides real benefit? If the prologue_cache is purged at the same time as the frame obstack then the two have the same lifetime. If that is the case then I think that the prologue analysis might as well be left in the frame object in ``struct frame_extra_info''. The only other possibility I can think of is is something like an inferior function call where GDB comes back to that exact same address. For a recursive call, the register info would be wrong. So anyone enlighten me as to when exactly this thing kicks in? :-) > 2000-02-23 Fernando Nasser > > * gdbint.texinfo: Add entry for target dependent macro > FLUSH_PROLOGUE_CACHE. > *** blockframe.c 1999/12/22 21:45:03 1.1.1.11 > --- blockframe.c 2000/02/23 00:17:15 > *************** flush_cached_frames () > *** 269,274 **** > --- 269,277 ---- > > current_frame = NULL; /* Invalidate cache */ > select_frame (NULL, -1); > + #ifdef FLUSH_PROLOGUE_CACHE > + FLUSH_PROLOGUE_CACHE (); > + #endif > annotate_frames_invalid (); > } > As an asside, this won't work well with multi-arch. enjoy, Andrew >From ac131313@cygnus.com Mon Feb 28 23:00:00 2000 From: Andrew Cagney To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFC: Frame cache s not always available. Date: Mon, 28 Feb 2000 23:00:00 -0000 Message-id: <38BB6E31.203DD244@cygnus.com> References: <38B40EB5.E9503E1C@redhat.com> X-SW-Source: 2000-02/msg00066.html Content-length: 2531 Fernando Nasser wrote: > > We are starting to talk about situations where the frames should not > considered valid. For some oversighting, or maybe because it is > gradually being implemented, gdb only tests for the return value of > get_current_frame() in one place and assumes in several places that > selected_frame is set. > > I found two places that are more troublesome and created the attached > patch. I did implement the frame invalid situation in the arm target > (on my sandbox only) and this two changes alone were enough. We may > found a few others in the future, and the situation were we do not have > a current or selected frame are not checked in yet, but I believe we > should make the code more robust and check this patch in anyway. FYI, I applied the attatched. Andrew Tue Feb 29 17:33:49 2000 Andrew Cagney From Wed, 23 Feb 2000 Fernando Nasser : * stack.c (backtrace_command_1), infrun.c (normal_stop): Check that the target's stack was valid. Index: infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.3 diff -p -r1.3 infrun.c *** infrun.c 2000/02/23 00:25:42 1.3 --- infrun.c 2000/02/29 06:54:55 *************** The same program may be running in anoth *** 3429,3435 **** bpstat_print() contains the logic deciding in detail what to print, based on the event(s) that just occurred. */ ! if (stop_print_frame) { int bpstat_ret; int source_flag; --- 3429,3436 ---- bpstat_print() contains the logic deciding in detail what to print, based on the event(s) that just occurred. */ ! if (stop_print_frame ! && selected_frame) { int bpstat_ret; int source_flag; Index: stack.c =================================================================== RCS file: /cvs/src/src/gdb/stack.c,v retrieving revision 1.2 diff -p -r1.2 stack.c *** stack.c 2000/02/08 04:39:02 1.2 --- stack.c 2000/02/29 06:55:00 *************** backtrace_command_1 (count_exp, show_loc *** 1111,1116 **** --- 1111,1122 ---- printing. Second, it must set the variable count to the number of frames which we should print, or -1 if all of them. */ trailing = get_current_frame (); + + /* The target can be in a state where there is no valid frames + (e.g., just connected). */ + if (trailing == NULL) + error ("No stack."); + trailing_level = 0; if (count_exp) { >From tromey@cygnus.com Mon Feb 28 23:01:00 2000 From: Tom Tromey To: Andrew Cagney Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Patch: make "!" a command unconditionally Date: Mon, 28 Feb 2000 23:01:00 -0000 Message-id: <200002290701.XAA15591@ferrule.cygnus.com> References: <87itz9cabi.fsf@cygnus.com> <38BB5D9F.1A9BF1B3@cygnus.com> X-SW-Source: 2000-02/msg00067.html Content-length: 734 >>>>> "Andrew" == Andrew Cagney writes: Andrew> From memory this has been suggested before. The problem pointed out Andrew> last time was that you need to specify: Andrew> ``!'' I suggested it last time but didn't supply a patch. I agree it would be nice to eliminate the space. That's probably more than a 20 second hack though :-( Andrew> I think there also may have been a debate over ``!'' as a Andrew> shell escape vs ``!'' for history. (personally it didn't Andrew> worry me). Fernando? This doesn't bother me either. For these kinds of tools "!" is more typically a shell escape. Speaking of history, I wish gdb would pick up bash's "C-o" (operate-and-get-next) binding. Tom >From ac131313@cygnus.com Mon Feb 28 23:03:00 2000 From: Andrew Cagney To: dan@cgsoftware.com Cc: Fernando Nasser , gdb-patches@sourceware.cygnus.com Subject: Re: RFC: Frame cache s not always available. Date: Mon, 28 Feb 2000 23:03:00 -0000 Message-id: <38BB6EBB.6F565574@cygnus.com> References: <38B40EB5.E9503E1C@redhat.com> X-SW-Source: 2000-02/msg00068.html Content-length: 1413 Daniel Berlin wrote: > > >>>>> "FN" == Fernando Nasser writes: > > FN> considered valid. For some oversighting, or maybe because it is > FN> gradually being implemented, gdb only tests for the return value of > FN> get_current_frame() in one place and assumes in several places that > FN> selected_frame is set. > > FN> I found two places that are more troublesome and created the attached > FN> patch. I did implement the frame invalid situation in the arm target > FN> (on my sandbox only) and this two changes alone were enough. We may > FN> found a few others in the future, and the situation were we do not > FN> have a current or selected frame are not checked in yet, but I believe > FN> we should make the code more robust and check this patch in anyway. > > I've found a few places in the code as well where the frame is invalid > because we switched threads. > I had to manually force gdb to reinit the frame cache, or else we wouldn't > have the right frames. > > However, i believe this may be a side effect of the way the beos port is > done, so i have them #ifdef'd for BEOS. > Just wanted to throw this out in case someone was working with threads and > saw incorrect stack backtraces. > --Dan I'd suspect that it was a bug. Must likely the reason it hasn't been noticed is that BE goes places where other OS's fear to tread :-) Andrew >From ac131313@cygnus.com Mon Feb 28 23:08:00 2000 From: Andrew Cagney To: Jim Kingdon Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFC: Frame cache s not always available. Date: Mon, 28 Feb 2000 23:08:00 -0000 Message-id: <38BB6FBE.6261782D@cygnus.com> References: <38B40EB5.E9503E1C@redhat.com> X-SW-Source: 2000-02/msg00069.html Content-length: 414 Jim Kingdon wrote: > > I don't see problems with this patch, except that I think I'd change > "No stack." to "No frames.". The former could be pretty confusing > since it also means things like "there is no memory which GDB knows > about". Turns out that everywhere else ``No Stack.'' was being used. (Besides, no-frames makes me think of web pages - is there a web browser in GDBtk yet? :-) enjoy, Andrew >From ac131313@cygnus.com Mon Feb 28 23:22:00 2000 From: Andrew Cagney To: fernando@cygnus.com Cc: GDB Patches Subject: [PATCH] Include in arm-tdep.c Date: Mon, 28 Feb 2000 23:22:00 -0000 Message-id: <38BB738C.ED57ED7C@cygnus.com> X-SW-Source: 2000-02/msg00070.html Content-length: 682 FYI, I've applied the attatched. Andrew Tue Feb 29 18:09:46 2000 Andrew Cagney * arm-tdep.c: Include . Index: arm-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/arm-tdep.c,v retrieving revision 1.3 diff -p -r1.3 arm-tdep.c *** arm-tdep.c 2000/02/17 19:51:04 1.3 --- arm-tdep.c 2000/02/29 07:18:29 *************** *** 28,33 **** --- 28,34 ---- #include "gdb_string.h" #include "coff/internal.h" /* Internal format of COFF symbols in BFD */ #include "dis-asm.h" /* For register flavors. */ + #include /* for isupper () */ extern void _initialize_arm_tdep (void); >From ac131313@cygnus.com Mon Feb 28 23:46:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Some compiler warnings removed Date: Mon, 28 Feb 2000 23:46:00 -0000 Message-id: <38BB78FF.FBD9A73D@cygnus.com> References: <200002232235.RAA18817@indy.delorie.com> X-SW-Source: 2000-02/msg00071.html Content-length: 5652 Eli Zaretskii wrote: > > Here's my share of shutting up "gcc -Wall -W". Is "foo = foo;" an > okay solution for unused argument foo? > > These diffs are against Feb 17 snapshot. I hope they are still > relevant and apply cleanly. > > 2000-02-23 Eli Zaretskii > > * utils.c [__GO32__]: Include pc.h, for prototypes of ScreenCols > and ScreenRows. > > * ser-go32.c: Include string.h, for prototype of strncasecmp. > (dpmi_regs, dpmi_sregs): Remove unused variables. > (dos_flush_input): Return a value, to prevent compiler warning. > > * main.c (captured_command_loop): Prevent gcc from complaining > about unused argument. > > * gdbtypes.c (count_virtual_fns): Make sure vfuncs is initialized > to zero. > > * expprint.c (dump_prefix_expression): Use %ld in format and cast > sizeof(union exp_element) to long, to prevent GCC from complaining > about format/argument mismatch. > (dump_postfix_expression): Likewise. > > * blockframe.c (nonnull_frame_chain_valid) > (pc_in_call_dummy_before_text_end) > (pc_in_call_dummy_after_text_end) > (pc_in_call_dummy_at_entry_point, generic_pc_in_call_dummy): > Prevent gcc from complaining about unused arguments. FYI, I pruned it back a bit and applied the attatched. Now if someone would just change gcc :-) Andrew Tue Feb 29 18:40:08 2000 Andrew Cagney From 2000-02-23 Eli Zaretskii : * utils.c [__GO32__]: Include pc.h, for prototypes of ScreenCols and ScreenRows. * ser-go32.c: Include string.h, for prototype of strncasecmp. (dpmi_regs, dpmi_sregs): Remove unused variables. (dos_flush_input): Return a value, to prevent compiler warning. * expprint.c (dump_prefix_expression): Use %ld in format and cast sizeof(union exp_element) to long, to prevent GCC from complaining about format/argument mismatch. (dump_postfix_expression): Likewise. Index: expprint.c =================================================================== RCS file: /cvs/src/src/gdb/expprint.c,v retrieving revision 1.1.1.6 diff -p -r1.1.1.6 expprint.c *** expprint.c 2000/02/02 00:21:06 1.1.1.6 --- expprint.c 2000/02/29 07:39:25 *************** dump_prefix_expression (exp, stream, not *** 710,718 **** print_expression (exp, stream); else fprintf_filtered (stream, "Type printing not yet supported...."); ! fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %d bytes each.\n", exp->language_defn->la_name, exp->nelts, ! sizeof (union exp_element)); fprintf_filtered (stream, "\t%5s %20s %16s %s\n", "Index", "Opcode", "Hex Value", "String Value"); for (elt = 0; elt < exp->nelts; elt++) --- 710,718 ---- print_expression (exp, stream); else fprintf_filtered (stream, "Type printing not yet supported...."); ! fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %ld bytes each.\n", exp->language_defn->la_name, exp->nelts, ! (long) sizeof (union exp_element)); fprintf_filtered (stream, "\t%5s %20s %16s %s\n", "Index", "Opcode", "Hex Value", "String Value"); for (elt = 0; elt < exp->nelts; elt++) *************** dump_postfix_expression (exp, stream, no *** 986,994 **** print_expression (exp, stream); else fputs_filtered ("Type printing not yet supported....", stream); ! fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %d bytes each.\n", exp->language_defn->la_name, exp->nelts, ! sizeof (union exp_element)); fputs_filtered ("\n", stream); for (elt = 0; elt < exp->nelts;) --- 986,994 ---- print_expression (exp, stream); else fputs_filtered ("Type printing not yet supported....", stream); ! fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %ld bytes each.\n", exp->language_defn->la_name, exp->nelts, ! (long) sizeof (union exp_element)); fputs_filtered ("\n", stream); for (elt = 0; elt < exp->nelts;) Index: ser-go32.c =================================================================== RCS file: /cvs/src/src/gdb/ser-go32.c,v retrieving revision 1.1.1.5 diff -p -r1.1.1.5 ser-go32.c *** ser-go32.c 2000/02/02 00:21:10 1.1.1.5 --- ser-go32.c 2000/02/29 07:39:27 *************** *** 127,141 **** #define MSR_DDSR 0x02 #define MSR_DCTS 0x01 #include #include #include typedef unsigned long u_long; - /* DPMI Communication */ - static union REGS dpmi_regs; - static struct SREGS dpmi_sregs; - /* 16550 rx fifo trigger point */ #define FIFO_TRIGGER FIFO_TRIGGER_4 --- 127,138 ---- #define MSR_DDSR 0x02 #define MSR_DCTS 0x01 + #include #include #include #include typedef unsigned long u_long; /* 16550 rx fifo trigger point */ #define FIFO_TRIGGER FIFO_TRIGGER_4 *************** dos_flush_input (scb) *** 693,698 **** --- 690,696 ---- if (port->fifo) outb (port, com_fifo, FIFO_ENABLE | FIFO_RCV_RST | FIFO_TRIGGER); enable (); + return 0; } static void Index: utils.c =================================================================== RCS file: /cvs/src/src/gdb/utils.c,v retrieving revision 1.1.1.26 diff -p -r1.1.1.26 utils.c *** utils.c 2000/02/02 00:21:11 1.1.1.26 --- utils.c 2000/02/29 07:39:34 *************** *** 31,36 **** --- 31,40 ---- #include #endif + #ifdef __GO32__ + #include + #endif + /* SunOS's curses.h has a '#define reg register' in it. Thank you Sun. */ #ifdef reg #undef reg >From ac131313@cygnus.com Tue Feb 29 00:03:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: DJGPP build and cleanup Date: Tue, 29 Feb 2000 00:03:00 -0000 Message-id: <38BB7BDD.39EEFE54@cygnus.com> References: <200002232229.RAA18809@indy.delorie.com> X-SW-Source: 2000-02/msg00072.html Content-length: 851 Eli Zaretskii wrote: > 2000-02-23 Eli Zaretskii > > * config/i386/nm-go32.h (FLOAT_INFO): Remove macro definition. > (top level): Add prototypes for go32_* functions. > > * config/i386/tm-go32.h (I386_DJGPP_TARGET): Define. > (FRAME_CHAIN, FRAMELESS_FUNCTION_INVOCATION, FRAME_SAVED_PC): > Override definitions from tm-i386.h. > (REGISTER_VIRTUAL_TYPE): Remove macro definition. > > * 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. FYI, I've checked this in. The only mod I made was to add a FIXME to i386_extract_return_value() pointing out that the function should be multi-arched. Hope it matches what you had, Andrew >From Peter.Schauer@regent.e-technik.tu-muenchen.de Tue Feb 29 01:23:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: Re: Patches to add i387 support to Solaris x86 platforms (withdrawn) Date: Tue, 29 Feb 2000 01:23:00 -0000 Message-id: <200002290923.KAA07207@reisser.regent.e-technik.tu-muenchen.de> References: <200002240845.JAA27280@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-02/msg00073.html Content-length: 175 These patches are withdrawn, they are superseded by http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00398.html -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From ac131313@cygnus.com Tue Feb 29 05:01:00 2000 From: Andrew Cagney To: "Peter.Schauer" Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Problem with gdb/objfiles.c and --with-mmalloc + fix Date: Tue, 29 Feb 2000 05:01:00 -0000 Message-id: <38BBC28D.D11E522C@cygnus.com> References: <200002232157.WAA26169@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-02/msg00074.html Content-length: 435 "Peter.Schauer" wrote: > > I have used --with-mmalloc with GDB configure for a long time to get sort of > a poor man's purify. Unfortunately gdb/objfiles.c suffered some bitrot > during the last year, here is a fix: > > 2000-02-23 Peter Schauer > > * objfiles.c (open_mapped_file): Fix obsolete references to `mapped' > parameter. > I've checked this in. thanks! Andrew >From ac131313@cygnus.com Tue Feb 29 05:31:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: PATCH: update i386 port to use FRAME_INIT_SAVED_REGS() Date: Tue, 29 Feb 2000 05:31:00 -0000 Message-id: <38BBC9F6.E847B7F@cygnus.com> References: <5mbt5vrxxp.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-02/msg00075.html Content-length: 1450 "J.T. Conklin" wrote: > > Moving the master GDB repository to sourceware provided the motivation > for me to sync up to the most recent snapshots, compare my repository, > and try to minimize the divergence. Easier than finishing the memory > region attribute code... > > Most of these are patches that have been submitted before but were not > rejected. > > >From the original submission: "I made this change a while ago, back > when Andrew was making similar changes to other targets. It's been in > my sources for some time, I found it again when I was checking the > differences between my repository and the last snapshot." > > The enclosed ChangeLog is from the original message. The patch is > relative to the 20000204 snapshot. > > --jtc > > 1999-08-13 J.T. Conklin > > * config/i386/tm-i386.h (FRAME_INIT_SAVED_REGS): Replace > FRAME_FIND_SAVED_REGS. > (i386_frame_init_saved_regs): Replace i386_frame_find_saved_regs. > * i386-tdep.c (i386_frame_init_saved_regs, i386_pop_frame): > Update. FYI, I've checked this in. (And run basic checks on an NetBSD/i386 machine). All the */i386 maintainers should make a mental note (but I don't expect problems). Other non i386 maintainers should also think about doing this conversion the next time they go to tidy up their target. It's about the hardest thing to fix when wanting to use any multi-arch code. Andrew >From ac131313@cygnus.com Tue Feb 29 05:41:00 2000 From: Andrew Cagney To: "Peter.Schauer" Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch to fix thread support for Solaris x86 Date: Tue, 29 Feb 2000 05:41:00 -0000 Message-id: <38BBCC0E.8EBC301A@cygnus.com> References: <200002261228.NAA32377@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-02/msg00076.html Content-length: 478 "Peter.Schauer" wrote: > > This patch fixes thread support for Solaris x86 platforms. > > The patch gets rid of the following testsuite fail and causes no regressions: > FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2 > > 2000-02-26 Peter Schauer > > * config/i386/tm-i386sol2.h (MERGEPID): Define. Thanks - I've checked it in. (Wonder if there should be a common config/tm-sol2.h?) Andrew >From ac131313@cygnus.com Tue Feb 29 05:54:00 2000 From: Andrew Cagney To: "Peter.Schauer" Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patches to allow GDB to use NEW_PROC_API on Solaris x86 Date: Tue, 29 Feb 2000 05:54:00 -0000 Message-id: <38BBCF0F.B38E9DB3@cygnus.com> References: <200002281744.SAA05324@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-02/msg00077.html Content-length: 1240 "Peter.Schauer" wrote: > > These patches will allow GDB to use NEW_PROC_API on Solaris x86. > > Currently GDB is not yet configured to use NEW_PROC_API, but it might be > in the future (I am making progress on hardware watchpoint support for > Solaris x86, which works only under the new API). > > They clean up an old hack in sol-thread.c, which is no longer necessary > with the new procfs.c code (thanks a lot Michael Snyder, I assume that you > will have to approve these patches also). > > The patches cause no testsuite regressions, with or without NEW_PROC_ABI > defined. > > 2000-02-28 Peter Schauer > > Make NEW_PROC_ABI interface functional on Solaris x86. > * sol-thread.c (ps_lgetLDT): Rewrite to use new procfs_find_LDT_entry > function from procfs.c, mostly copied from lin-thread.c. > * inferior.h, procfs.c (procfs_get_pid_fd): Removed, no longer needed. > I've applied the attatched. One observation - I like how the comment: > ! /* NOTE: only used on Solaris, therefore OK to refer to procfs.c */ > ! extern struct ssd *procfs_find_LDT_entry (int); > ! struct ssd *ret; was coppied to lin-thread.c and then back again :-) Andrew >From ac131313@cygnus.com Tue Feb 29 06:02:00 2000 From: Andrew Cagney To: Maurizio Palesi Cc: gdb-patches@sourceware.cygnus.com Subject: Re: instruction trace file Date: Tue, 29 Feb 2000 06:02:00 -0000 Message-id: <38BBD13C.6D6F51AE@cygnus.com> References: <38BA76BC.62659DF8@sun131.iit.unict.it> X-SW-Source: 2000-02/msg00078.html Content-length: 550 Maurizio Palesi wrote: > > Hi all, > Is there a method to generate an instruction by instruction > execution trace file of a program? From an executable file i wish to > obtain an instruction trace file with following information: > - address where instruction was fetched > - instruction name > - if memory access: address and data > Thanks to all, > Maurizio Using one of GDB's simulators then probably yes. Using gdb and a normal target probably not (it would manage the insn address/name but not the memory accesses). enjoy, Andrew >From ac131313@cygnus.com Tue Feb 29 06:03:00 2000 From: Andrew Cagney To: GDB Patches Subject: [Fwd: Updated tools] Date: Tue, 29 Feb 2000 06:03:00 -0000 Message-id: <38BBD180.5EBCF466@cygnus.com> X-SW-Source: 2000-02/msg00079.html Content-length: 380 Now what this means for GDB I'm not sure. Andrew To : binutils at sourceware dot cygnus dot com Subject : Updated tools >From : Ian Lance Taylor Date : 27 Feb 2000 11:58:18 -0500 I updated the snapshots of autoconf, automake, libtool and gettext in ftp://sourceware.cygnus.com/pub/binutils . I rebuilt the generated files using the new sources. Ian