From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephane Carrez To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Fri, 05 Jan 2001 11:56:00 -0000 Message-id: <3A562753.155306F0@worldnet.fr> References: <200101032042.PAA14850@nog.bosbc.com> X-SW-Source: 2001-01/msg00053.html Hi All and Happy new Millenium! Nicholas Duffek wrote: > This patch introduces a new interface for defining registers in GDB. It > applies over the two regcache.c patches I posted earlier. Well done!!! Hope to have this integrated soon! Do you have any target specific patch/example to use that? (IA64?) I would like to have some example to try the memory mapped registers in the 68HC11/68HC12 port. > Since this and the other regcache.c patch are so large and touch such a > fundamental piece of GDB, I'll commit them after a 2-day waiting period. Don't wait too much :-) :-) :-) Stephane ----------------------------------------------------------------------- Home Office E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com WWW: http://home.worldnet.fr/stcarrez http://www.sun.com Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel 92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines France >From nsd@redhat.com Fri Jan 05 12:30:00 2001 From: Nick Duffek To: Stephane.Carrez@worldnet.fr Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Fri, 05 Jan 2001 12:30:00 -0000 Message-id: <200101052038.f05KcBB04727@rtl.cygnus.com> References: <3A562753.155306F0@worldnet.fr> X-SW-Source: 2001-01/msg00054.html Content-length: 1839 On 5-Jan-2001, Stephane Carrez wrote: >Do you have any target specific patch/example to use that? Not that I can release at the moment, but I have tested it with one architecture so far. >I would like to have some example to try the memory mapped registers in >the 68HC11/68HC12 port. You'll need to use regs_init_mem() instead of regs_init_real(). Here's the example I posted initially for architecture "foo", modified for registers memory-mapped contiguously from address 0: r0..r31 32-bit data registers, starting at address 0x0 sp stack pointer, at address 0x80 ret return value register, alias for r0 static void foo_init_regs (struct gdbarch *gdbarch) { struct regs_init_context *context; char name[4]; int i, parents[2]; CORE_ADDR mem; context = regs_init_start (gdbarch, foo_caller_regs); /* General data registers. */ for (i = 0, mem = 0x0; i < 32; i++, mem += 4) { sprintf (name, "r%d", i); regs_init_mem (context, name, i, 4, &builtin_type_int32, mem, 0); } /* Stack pointer. */ regs_init_mem (context, "sp", FOO_SP_REGNUM, 4, &builtin_type_CORE_ADDR, 0x80, 0); /* Return value. */ parents[0] = 0; parents[1] = -1; regs_init_pseudo (context, "ret", 4, &builtin_type_int32, REGS_HIDEALL, regs_rpseudo_alias, regs_wpseudo_alias, NULL, parents); regs_init_finish (context); } >> Since this and the other regcache.c patch are so large and touch such a >> fundamental piece of GDB, I'll commit them after a 2-day waiting period. Note that by "them", I meant the two regcache.c patches needed for the big register interface patch, which still hasn't gotten approved. >Don't wait too much :-) :-) :-) :-) I'll commit it as soon as it gets approved, Nick >From eliz@is.elta.co.il Sat Jan 06 01:03:00 2001 From: "Eli Zaretskii" To: dan@redhat.com Cc: gdb-patches@sources.redhat.com, fnasser@redhat.com, jimb@redhat.com Subject: Re: [PATCH]: Symbol origin patch, with changelog Date: Sat, 06 Jan 2001 01:03:00 -0000 Message-id: <7458-Sat06Jan2001105957+0200-eliz@is.elta.co.il> References: X-SW-Source: 2001-01/msg00055.html Content-length: 1371 > Date: Fri, 5 Jan 2001 13:46:27 -0500 (EST) > From: Daniel Berlin > > SYmbol origin patch again, with changelog this time. > I made the small change Eli requested to the documentation as well. Thans. The doco patches are approved, except for this minor nitpicking: > + @item show print origin > + Show whether or not @value{GDBN} will print the origin of a symbol when > + printing a symbol name. > + @end table This needs a @kindex entry. > + struct objfile * > + lookup_objfile (const char *name) > + { > + register char *slash; > + register struct objfile *objfile; > + register struct objfile *result; > + > + /* First, search for an exact match */ > + > + ALL_OBJFILES (objfile) > + if (STREQ (name, objfile->name)) > + return objfile; > + > + slash = strchr (name, '/'); Bother. Are we sure that some DOSish platform, such as MinGW, won't use backslashes in objfiles? (I don't think this is a problem with DJGPP, at least not with native COFF debugging, because there are no leading directories in COFF debug info.) Also, there are all kinds of complications with the drive letter brain-damage, e.g., the file name could be d:foo.o. If backslashes _can_ appear, perhaps you should simply call basename from the system library, or provide a portable version of it which does TRT on each platform? >From cgf@redhat.com Sat Jan 06 08:58:00 2001 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [PATCH]: Symbol origin patch, with changelog Date: Sat, 06 Jan 2001 08:58:00 -0000 Message-id: <20010106115850.D13257@redhat.com> References: <7458-Sat06Jan2001105957+0200-eliz@is.elta.co.il> X-SW-Source: 2001-01/msg00056.html Content-length: 542 On Sat, Jan 06, 2001 at 10:59:58AM +0200, Eli Zaretskii wrote: >> + slash = strchr (name, '/'); > >Bother. Are we sure that some DOSish platform, such as MinGW, won't >use backslashes in objfiles? (I don't think this is a problem with >DJGPP, at least not with native COFF debugging, because there are no >leading directories in COFF debug info.) Also, there are all kinds of >complications with the drive letter brain-damage, e.g., the file name >could be d:foo.o. I *think* that recent versions of bfd convert all '\'s to '/'s. cgf >From msokolov@ivan.Harhan.ORG Sun Jan 07 23:48:00 2001 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: gdb-patches@sources.redhat.com Subject: [patch] to readline: compilation-stopping typo Date: Sun, 07 Jan 2001 23:48:00 -0000 Message-id: <0101080747.AA07066@ivan.Harhan.ORG> X-SW-Source: 2001-01/msg00057.html Content-length: 2000 Hi there, I've just started (never had a need for a debugger before) trying to build gdb (current CVS) on my system (4.3BSD), and I've immediately hit this compilation- stopping typo in readline: a missing semicolon! I can't imagine how everybody else is building gdb, it must be that this bit of code isn't compiled on the systems everybody else uses I guess. The patch is below. However, how do I get it in? readline in the Cygnus tree / gdb is imported from an outside source. I've checked the indicated official version (readline-4.1 from ftp.cwru.edu), and it has exactly the same bug. What's the right procedure for fixing this? -- Michael Sokolov Public Service Agent International Engineering and Science Task Force 1351 VINE AVE APT 27 Phone: +1-714-738-5409 FULLERTON CA 92833-4291 USA (home office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) 2001-01-07 Michael Sokolov * rltty.c (save_tty_chars): Fix compilation-stopping typo. Index: rltty.c =================================================================== RCS file: /cvs/src/src/readline/rltty.c,v retrieving revision 1.4 diff -p -r1.4 rltty.c *** rltty.c 2000/07/09 17:19:56 1.4 --- rltty.c 2001/01/06 00:47:27 *************** save_tty_chars (tiop) *** 190,196 **** _rl_tty_chars.t_intr = tiop->tchars.t_intrc; _rl_tty_chars.t_quit = tiop->tchars.t_quitc; _rl_tty_chars.t_start = tiop->tchars.t_startc; ! _rl_tty_chars.t_stop = tiop->tchars.t_stopc _rl_tty_chars.t_eof = tiop->tchars.t_eofc; _rl_tty_chars.t_eol = '\n'; _rl_tty_chars.t_eol2 = tiop->tchars.t_brkc; --- 190,196 ---- _rl_tty_chars.t_intr = tiop->tchars.t_intrc; _rl_tty_chars.t_quit = tiop->tchars.t_quitc; _rl_tty_chars.t_start = tiop->tchars.t_startc; ! _rl_tty_chars.t_stop = tiop->tchars.t_stopc; _rl_tty_chars.t_eof = tiop->tchars.t_eofc; _rl_tty_chars.t_eol = '\n'; _rl_tty_chars.t_eol2 = tiop->tchars.t_brkc; >From cgf@redhat.com Mon Jan 08 06:59:00 2001 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [patch] to readline: compilation-stopping typo Date: Mon, 08 Jan 2001 06:59:00 -0000 Message-id: <20010108095933.F26292@redhat.com> References: <0101080747.AA07066@ivan.Harhan.ORG> X-SW-Source: 2001-01/msg00058.html Content-length: 1134 On Sun, Jan 07, 2001 at 11:47:40PM -0800, Michael Sokolov wrote: >I've just started (never had a need for a debugger before) trying to build gdb >(current CVS) on my system (4.3BSD), and I've immediately hit this compilation- >stopping typo in readline: a missing semicolon! I can't imagine how everybody >else is building gdb, it must be that this bit of code isn't compiled on the >systems everybody else uses I guess. That's really strange. It's hard to believe that no one else has been hit by this problem before. Maybe you're the only person diligent enough to report it! >The patch is below. However, how do I get it in? readline in the Cygnus tree / >gdb is imported from an outside source. I've checked the indicated official >version (readline-4.1 from ftp.cwru.edu), and it has exactly the same bug. >What's the right procedure for fixing this? I've checked in the patch into the readline sources at sources.redhat.com. The next step is for you to contact the readline author and let him know about the problem. Then the next time we import readline we won't have to remember to make this change again. Thanks, cgf >From fnasser@cygnus.com Mon Jan 08 07:35:00 2001 From: Fernando Nasser To: Fernando Nasser Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: [infrun.c] Fix to "nexti". Date: Mon, 08 Jan 2001 07:35:00 -0000 Message-id: <3A59DE42.5295C9A5@cygnus.com> References: <3A54D5D2.CCA3E45E@redhat.com> X-SW-Source: 2001-01/msg00059.html Content-length: 2139 Ping! Fernando Nasser wrote: > > A "nexti" inside a function prologue currently == continue. > This has been broken for quite a while (24-Oct-95). > > Here is the fix. > > * infrun.c (handle_inferior_event): Handle "nexti" inside function > prologues. > > -- > Fernando Nasser > Red Hat Canada Ltd. E-Mail: fnasser@redhat.com > 2323 Yonge Street, Suite #300 > Toronto, Ontario M4P 2C9 > > > Index: infrun.c > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/infrun.c,v > retrieving revision 1.277 > diff -c -p -r1.277 infrun.c > *** infrun.c 2000/02/29 07:17:52 1.277 > --- infrun.c 2001/01/04 19:39:44 > *************** handle_inferior_event (struct execution_ > *** 2738,2748 **** > { > /* It's a subroutine call. */ > > ! if (step_over_calls == STEP_OVER_NONE) > { > /* I presume that step_over_calls is only 0 when we're > supposed to be stepping at the assembly language level > ("stepi"). Just stop. */ > stop_step = 1; > print_stop_reason (END_STEPPING_RANGE, 0); > stop_stepping (ecs); > --- 2738,2753 ---- > { > /* It's a subroutine call. */ > > ! if ((step_over_calls == 0) > ! || ((step_range_end == 1) > ! && in_prologue (prev_pc, ecs->stop_func_start))) > { > /* I presume that step_over_calls is only 0 when we're > supposed to be stepping at the assembly language level > ("stepi"). Just stop. */ > + /* Also, maybe we just did a "nexti" inside a prolog, > + so we thought it was a subroutine call but it was not. > + Stop as well. FENN */ > stop_step = 1; > print_stop_reason (END_STEPPING_RANGE, 0); > stop_stepping (ecs); -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From msokolov@ivan.Harhan.ORG Mon Jan 08 14:43:00 2001 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: gdb-patches@sources.redhat.com Subject: Re: [patch] to readline: compilation-stopping typo Date: Mon, 08 Jan 2001 14:43:00 -0000 Message-id: <0101082014.AA08728@ivan.Harhan.ORG> X-SW-Source: 2001-01/msg00060.html Content-length: 997 Christopher Faylor wrote: > That's really strange. It's hard to believe that no one else has been hit by > this problem before. Maybe you're the only person diligent enough to report it! See below. > I've checked in the patch into the readline sources at sources.redhat.com. Thanks. > The next step is for you to contact the readline author and let him know about > the problem. Then the next time we import readline we won't have to remember > to make this change again. I've sent the patch to Chet Ramey and he responded that he had already fixed this. He also said that this code is used only on 4.3BSD. This certainly explains why no one else has been hit by this before (I use and maintain 4.3BSD in opposition to the rest of the world). -- Michael Sokolov Public Service Agent International Engineering and Science Task Force 1351 VINE AVE APT 27 Phone: +1-714-738-5409 FULLERTON CA 92833-4291 USA (home office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) >From cgf@redhat.com Mon Jan 08 15:05:00 2001 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [patch] to readline: compilation-stopping typo Date: Mon, 08 Jan 2001 15:05:00 -0000 Message-id: <20010108180545.C1327@redhat.com> References: <0101082014.AA08728@ivan.Harhan.ORG> X-SW-Source: 2001-01/msg00061.html Content-length: 673 On Mon, Jan 08, 2001 at 12:14:55PM -0800, Michael Sokolov wrote: >> The next step is for you to contact the readline author and let him know about >> the problem. Then the next time we import readline we won't have to remember >> to make this change again. > >I've sent the patch to Chet Ramey and he responded that he had already fixed >this. He also said that this code is used only on 4.3BSD. This certainly >explains why no one else has been hit by this before (I use and maintain 4.3BSD >in opposition to the rest of the world). Yep. I knew you were using 4.3BSD but I thought that this would have been tickled by any BSD. Guess I didn't look closely enough. cgf >From nsd@redhat.com Mon Jan 08 16:23:00 2001 From: Nick Duffek To: msnyder@redhat.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Functionalize registers[] and register_valid[] Date: Mon, 08 Jan 2001 16:23:00 -0000 Message-id: <200101090031.f090VR800645@rtl.cygnus.com> References: <200101032118.f03LIrr02904@rtl.cygnus.com> X-SW-Source: 2001-01/msg00062.html Content-length: 240 On 3-Jan-2001, I wrote: >Since this and the other regcache.c patch are so large and touch such a >fundamental piece of GDB, I'll commit them after a 2-day waiting period. I've committed this patch and the previous regcache.c patch. Nick >From nsd@redhat.com Mon Jan 08 17:20:00 2001 From: Nicholas Duffek To: gdb-patches@sources.redhat.com Subject: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Mon, 08 Jan 2001 17:20:00 -0000 Message-id: <200101090128.f091SIq00850@rtl.cygnus.com> X-SW-Source: 2001-01/msg00063.html Content-length: 1638 This patch adjusts breakpoint addresses using BREAKPOINT_FROM_PC before rather than after storing them in Z packets. Elsewhere in GDB, BREAKPOINT_FROM_PC gets called before the address is passed to the target, so I think this patch is correct. I haven't tested it with a target that uses both Z packets and BREAKPOINT_FROM_PC, however. ChangeLog: * remote.c (remote_insert_breakpoint, remote_remove_breakpoint): Call BREAKPOINT_FROM_PC before rather than after storing the address in the outgoing Z packet. No regressions on i686-pc-linux-gnu. Okay to apply? Nicholas Duffek [patch follows] Index: gdb/remote.c =================================================================== diff -up gdb/remote.c gdb/remote.c --- gdb/remote.c Mon Jan 8 19:35:50 2001 +++ gdb/remote.c Mon Jan 8 19:35:26 2001 @@ -4250,12 +4250,13 @@ remote_insert_breakpoint (CORE_ADDR addr char *buf = alloca (PBUFSIZ); char *p = buf; - addr = remote_address_masked (addr); *(p++) = 'Z'; *(p++) = '0'; *(p++) = ','; - p += hexnumstr (p, (ULONGEST) addr); + + addr = remote_address_masked (addr); BREAKPOINT_FROM_PC (&addr, &bp_size); + p += hexnumstr (p, (ULONGEST) addr); sprintf (p, ",%d", bp_size); putpkt (buf); @@ -4306,8 +4307,8 @@ remote_remove_breakpoint (CORE_ADDR addr *(p++) = ','; addr = remote_address_masked (addr); - p += hexnumstr (p, (ULONGEST) addr); BREAKPOINT_FROM_PC (&addr, &bp_size); + p += hexnumstr (p, (ULONGEST) addr); sprintf (p, ",%d", bp_size); putpkt (buf); >From jtc@redback.com Mon Jan 08 20:16:00 2001 From: jtc@redback.com (J.T. Conklin) To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Mon, 08 Jan 2001 20:16:00 -0000 Message-id: <5m1yudxsvf.fsf@jtc.redback.com> References: <200101090128.f091SIq00850@rtl.cygnus.com> X-SW-Source: 2001-01/msg00064.html Content-length: 2083 >>>>> "Nicholas" == Nicholas Duffek writes: Nicholas> This patch adjusts breakpoint addresses using Nicholas> BREAKPOINT_FROM_PC before rather than after storing them in Nicholas> Z packets. Nicholas> Nicholas> Elsewhere in GDB, BREAKPOINT_FROM_PC gets called before the Nicholas> address is passed to the target, so I think this patch is Nicholas> correct. I haven't tested it with a target that uses both Z Nicholas> packets and BREAKPOINT_FROM_PC, however. I'm a bit bothered by the fact BREAKPOINT_FROM_PC() is being used in the first place. The intent was for the debug agent to have freedom to implement software breakpoints using any mechanism, not requiring the agent to replace memory contents with the same byte sequence that GDB would have inserted if the Z/z command packets were not supported. The GDB internals manual indicates that BREAKPOINT_FROM_PC() may adjust the address. I don't know under what circumstances it does so, but it would seem that the debug agent could then install the break in the wrong location. I think the reason that BREAKPOINT_FROM_PC() is called is to get the size of the breakpoint. This feature was not in my original proposal. It was later added to handle those architectures that have both 16 and 32 bit modes with different breakpoint instructions depending on what mode the code is. I'm not fond of this --- there must be a better way. In a target where the debug agent is incorporated into the system, the agent could be made to "know" where the 16 and 32 bit .text sections are and insert the appropriate trap insn; but some people use the remote protocol as a low level ROM monitor to load and debug their code. In that case the agent wouldn't have enough information. As long as BREAKPOINT_FROM_PC() is able to change the breakpoint address, I don't think this patch is appropriate. In fact, if there was a better way for GDB to tell the agent what memory regions were 16 bit code and what were 32 bit codes, I'd remove it from this code completely. --jtc -- J.T. Conklin RedBack Networks >From nsd@redhat.com Mon Jan 08 21:09:00 2001 From: Nick Duffek To: jtc@redback.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Mon, 08 Jan 2001 21:09:00 -0000 Message-id: <200101090517.f095HBY01083@rtl.cygnus.com> References: <5m1yudxsvf.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00065.html Content-length: 1207 On 8-Jan-2001, J . T . Conklin wrote: >The GDB internals manual indicates that BREAKPOINT_FROM_PC() may >adjust the address. Yes, and that's exactly why I want to move it: so that the target architecture can adjust the address. (Specifically, I want to convert the address from a byte address to an instruction space pointer. This entails (a) removing the IMEM_START bit added by the harvard architecture mechanism and (b) dividing the address by 8.) >I think the reason that BREAKPOINT_FROM_PC() is called is to get the >size of the breakpoint. That's all it does prior to my patch. But elsewhere in GDB, namely in mem-break.c, BREAKPOINT_FROM_PC serves as a generic way for target architectures to modify the address and other attributes of a breakpoint before it hits the hardware. Maybe that's an argument for replacing target_insert_breakpoint() with a wrapper that calls BREAKPOINT_FROM_PC. >but it would seem that the debug agent could then install the break in >the wrong location. I don't think that's a problem. BREAKPOINT_FROM_PC doesn't modify the address unless the target architecture author explicitly causes it to do so, in which case it's presumably the right thing to do. Nick >From jtc@redback.com Tue Jan 09 10:59:00 2001 From: jtc@redback.com (J.T. Conklin) To: Nick Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Tue, 09 Jan 2001 10:59:00 -0000 Message-id: <5mn1d0wnz4.fsf@jtc.redback.com> References: <5m1yudxsvf.fsf@jtc.redback.com> <200101090517.f095HBY01083@rtl.cygnus.com> X-SW-Source: 2001-01/msg00066.html Content-length: 2581 >>>>> "Nick" == Nick Duffek writes: Nick> On 8-Jan-2001, J . T . Conklin wrote: >> The GDB internals manual indicates that BREAKPOINT_FROM_PC() may >> adjust the address. Nick> Yes, and that's exactly why I want to move it: so that the target Nick> architecture can adjust the address. Nick> Nick> (Specifically, I want to convert the address from a byte address Nick> to an instruction space pointer. This entails (a) removing the Nick> IMEM_START bit added by the harvard architecture mechanism and Nick> (b) dividing the address by 8.) Ok, I'm really confused. If BREAKPOINT_FROM_PC() is called to change GDB's internal notion of a breakpoint address to the cannonical target representation, why is it not used in every *_insert_breakpoint() and *_remove_breakpoint() vector function? It would seem to me that this transformation should be done before the functions are called. >> I think the reason that BREAKPOINT_FROM_PC() is called is to get the >> size of the breakpoint. Nick> That's all it does prior to my patch. But elsewhere in GDB, namely in Nick> mem-break.c, BREAKPOINT_FROM_PC serves as a generic way for target Nick> architectures to modify the address and other attributes of a breakpoint Nick> before it hits the hardware. But is these types of changes appropriate when GDB does not know how the target is going to implement the breakpoint? Nick> Maybe that's an argument for replacing target_insert_breakpoint() Nick> with a wrapper that calls BREAKPOINT_FROM_PC. Just read this... Yes, if address swizzling is necessary, I think it should be done before the vector functions are called. This may imply that BREAKPOINT_FROM_PC() be broken into parts, since returning the bytes string containing a break/trap insn is not necesary at that level. >> but it would seem that the debug agent could then install the break in >> the wrong location. Nick> I don't think that's a problem. BREAKPOINT_FROM_PC doesn't Nick> modify the address unless the target architecture author Nick> explicitly causes it to do so, in which case it's presumably the Nick> right thing to do. BREAKPOINT_FROM_PC() is at the arch level. A gdb for a given arch may support several targets. I'm still somewhat concerned that address swizzling for one target may not be appropriate for another. I'm probably just being paranoid. As long as it's only used to convert GDB's address representation to that used by the architecture, it might be safe to assume that all targets will need the same thing. --jtc -- J.T. Conklin RedBack Networks >From nsd@redhat.com Tue Jan 09 11:42:00 2001 From: Nick Duffek To: jtc@redback.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Tue, 09 Jan 2001 11:42:00 -0000 Message-id: <200101091950.f09Jobr01677@rtl.cygnus.com> References: <5mn1d0wnz4.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00067.html Content-length: 669 On 9-Jan-2001, J . T . Conklin wrote: >Yes, if address swizzling is necessary, I think it should be done before >the vector functions are called. I'll check into that. >A gdb for a given arch may support several targets. I'm still somewhat >concerned that address swizzling for one target may not be appropriate >for another. I'm probably just being paranoid. I'm a bit paranoid about prepending BREAKPOINT_FROM_PC to target_insert_breakpoint, but it does seem like the right approach. I'll bet that only a few archs use BREAKPOINT_FROM_PC to change the address, so it may be possible to be reasonably sure that no breakage would result. Patch withdrawn, Nick >From dsmith@redhat.com Tue Jan 09 12:11:00 2001 From: David Smith To: Nick Duffek Cc: jtc@redback.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Tue, 09 Jan 2001 12:11:00 -0000 Message-id: <3A5B7053.3374EB79@redhat.com> References: <5mn1d0wnz4.fsf@jtc.redback.com> <200101091950.f09Jobr01677@rtl.cygnus.com> X-SW-Source: 2001-01/msg00068.html Content-length: 1284 I'm not exactly sure what you are trying to do here, but Kevin Buettner posted a patch (that never got committed) that added a new architecture feature that explicitly adjusted a breakpoint address (if necessary). You might look at it for ideas if nothing else. The nice thing about it is that the address "swizzling" is very explicit. Here's a link: < http://sources.redhat.com/ml/gdb-patches/2000-06/msg00257.html > I hope this helps. Nick Duffek wrote: > > On 9-Jan-2001, J . T . Conklin wrote: > > >Yes, if address swizzling is necessary, I think it should be done before > >the vector functions are called. > > I'll check into that. > > >A gdb for a given arch may support several targets. I'm still somewhat > >concerned that address swizzling for one target may not be appropriate > >for another. I'm probably just being paranoid. > > I'm a bit paranoid about prepending BREAKPOINT_FROM_PC to > target_insert_breakpoint, but it does seem like the right approach. I'll > bet that only a few archs use BREAKPOINT_FROM_PC to change the address, so > it may be possible to be reasonably sure that no breakage would result. > > Patch withdrawn, > > Nick -- David Smith dsmith@redhat.com Red Hat, Inc. http://www.redhat.com 256.704.9222 (direct) 256.837.3839 (fax) >From nsd@redhat.com Tue Jan 09 12:27:00 2001 From: Nick Duffek To: dsmith@redhat.com Cc: gdb-patches@sources.redhat.com, jtc@redback.com Subject: Re: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC Date: Tue, 09 Jan 2001 12:27:00 -0000 Message-id: <200101092035.f09KZbe01747@rtl.cygnus.com> References: <3A5B7053.3374EB79@redhat.com> X-SW-Source: 2001-01/msg00069.html Content-length: 426 On 9-Jan-2001, David Smith wrote: >Kevin Buettner posted a patch (that never got committed) that added a new >architecture feature that explicitly adjusted a breakpoint address (if >necessary). Thanks, I'd forgotten about that. Unfortunately, it doesn't quite do what I want, which is for GDB to pretend to accept the user's breakpoint addresses as-is and then secretly change them before sending them to the target. Nick >From jtc@redback.com Wed Jan 10 13:34:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA]: memory region attributes Date: Wed, 10 Jan 2001 13:34:00 -0000 Message-id: <5m7l432isc.fsf@jtc.redback.com> References: <5msno2xs49.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00070.html Content-length: 629 >>>>> "jtc" == J T Conklin writes: jtc> Since I didn't get any comments from my RFC: jtc> http://sources.redhat.com/ml/gdb-patches/2000-11/msg00299.html jtc> http://sources.redhat.com/ml/gdb-patches/2000-11/msg00301.html jtc> jtc> I submit the enclosed patch for approval. This patch adds the infra- jtc> structure for memory region attributes. Ping! I've received approval for the documentation changes, but not for the code itself. I've already updated the copyright notices for 2001, so it's ready to commit once someone says the word. --jtc -- J.T. Conklin RedBack Networks >From nickc@redhat.com Thu Jan 11 13:31:00 2001 From: Nick Clifton To: gdb-patches@sources.redhat.com Subject: RFA: Fix to build arc-tdep.c with new ARC machine numbers Date: Thu, 11 Jan 2001 13:31:00 -0000 Message-id: <200101112131.NAA30844@elmo.cygnus.com> X-SW-Source: 2001-01/msg00071.html Content-length: 1736 Hi Guys, The ARC port in binutils was recently changes by a submission from Peter Taggert at arccores.com. This change introduced some new machine numbers for the ARC and also changed how the disassembler is invoked. The patch below makes adjustments to arc-tdep.c for both of these changes. OK to apply ? Cheers Nick 2001-01-11 Nick Clifton * arc-tdep.c (arc_cpu_type_table): Add new arc core numbers. (arc_print_insn): No bfd available, so pass NULL to arc_get_disassembler. Index: gdb/arc-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/arc-tdep.c,v retrieving revision 1.3 diff -p -r1.3 arc-tdep.c *** arc-tdep.c 2000/07/30 01:48:24 1.3 --- arc-tdep.c 2001/01/11 21:27:27 *************** struct *** 44,56 **** } arc_cpu_type_table[] = { ! { ! "base", bfd_mach_arc_base ! } ! , ! { ! NULL, 0 ! } }; /* Used by simulator. */ --- 44,54 ---- } arc_cpu_type_table[] = { ! { "arc5", bfd_mach_arc_5 }, ! { "arc6", bfd_mach_arc_6 }, ! { "arc7", bfd_mach_arc_7 }, ! { "arc8", bfd_mach_arc_8 }, ! { NULL, 0 } }; /* Used by simulator. */ *************** arc_print_insn (bfd_vma vma, disassemble *** 618,625 **** { current_mach = arc_bfd_mach_type; current_endian = TARGET_BYTE_ORDER; ! current_disasm = arc_get_disassembler (current_mach, ! current_endian == BIG_ENDIAN); } return (*current_disasm) (vma, info); --- 616,622 ---- { current_mach = arc_bfd_mach_type; current_endian = TARGET_BYTE_ORDER; ! current_disasm = arc_get_disassembler (NULL); } return (*current_disasm) (vma, info); >From mrg@cygnus.com Thu Jan 11 16:13:00 2001 From: matthew green To: gdb-patches@sources.redhat.com Subject: [patch] ARMulator XScale coprocessor extensions Date: Thu, 11 Jan 2001 16:13:00 -0000 Message-id: <24678.979258368@cygnus.com> X-SW-Source: 2001-01/msg00072.html Content-length: 25309 hi, this patch adds support for several of of the xscale coprocessor registers: - endianness bit support - set the FSR & FAR for relevant aborts - clock timer/counter support - data & instruction breakpoint support - sets the MOE (method of entry) for debugging - model FIQ & IRQ enable bits 2001-01-04 matthew green * armcopro.c (write_cp15_reg): Pass in ARMul_State so we can set CHANGEMODE if endianness changes. (read_cp15_reg): Make non-static. (XScale_cp15_LDC): Update for write_cp15_reg() change. (XScale_cp15_MCR): Likewise. (XScale_cp15_write_reg): Likewise. (XScale_check_memacc): New function. Check for breakpoints being activated by memory accesses. Does not support the Branch Target Buffer. (XScale_set_fsr_far): New function. Set FSR and FAR for XScale. (XScale_debug_moe): New function. Set the debug Method Of Entry, if configured. (write_cp14_reg): Reset count counter if requested. * armdefs.h (struct ARMul_State): New members `LastTime' and `CP14R0_CCD' used for the timer/counters. (ARMul_CP13_R0_FIQ, ARMul_CP13_R0_IRQ, ARMul_CP13_R8_PMUS, ARMul_CP14_R0_ENABLE, ARMul_CP14_R0_CLKRST, ARMul_CP14_R0_CCD, ARMul_CP14_R0_INTEN0, ARMul_CP14_R0_INTEN1, ARMul_CP14_R0_INTEN2, ARMul_CP14_R0_FLAG0, ARMul_CP14_R0_FLAG1, ARMul_CP14_R0_FLAG2, ARMul_CP14_R10_MOE_IB, ARMul_CP14_R10_MOE_DB, ARMul_CP14_R10_MOE_BT, ARMul_CP15_R1_ENDIAN, ARMul_CP15_R1_ALIGN, ARMul_CP15_R5_X, ARMul_CP15_R5_ST_ALIGN, ARMul_CP15_R5_IMPRE, ARMul_CP15_R5_MMU_EXCPT, ARMul_CP15_DBCON_M, ARMul_CP15_DBCON_E1, ARMul_CP15_DBCON_E0): New defines for XScale registers. (XScale_check_memacc, XScale_set_fsr_far, XScale_debug_moe): Prototype. (ARMul_Emulate32, ARMul_Emulate26): Clean up function definition. (ARMul_Emulate32): Handle the clock counter and hardware instruction breakpoints. Call XScale_set_fsr_far() for software breakpoints and software interrupts. (LoadMult): Call XScale_set_fsr_far() for data aborts. (LoadSMult): Likewise. (StoreMult): Likewise. (StoreSMult): Likewise. * armemu.h (write_cp15_reg): Update prototype. * arminit.c (ARMul_NewState): Initialise CP14R0_CCD and LastTime. (ARMul_Abort): If XScale, check for FIQ and IRQ being enabled in CP13 register 0. * armvirt.c (GetWord): Call XScale_check_memacc(). (PutWord): Likewise. Index: armcopro.c =================================================================== RCS file: /cvs/src/src/sim/arm/armcopro.c,v retrieving revision 1.4 diff -p -r1.4 armcopro.c *** armcopro.c 2000/11/30 01:55:12 1.4 --- armcopro.c 2001/01/10 05:18:20 *************** *** 16,21 **** --- 16,22 ---- Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include "armdefs.h" + #include "armos.h" #include "armemu.h" #include "ansidecl.h" *************** check_cp15_access (ARMul_State * state, *** 211,217 **** /* Store a value into one of coprocessor 15's registers. */ void ! write_cp15_reg (unsigned reg, unsigned opcode_2, unsigned CRm, ARMword value) { if (opcode_2) { --- 212,218 ---- /* Store a value into one of coprocessor 15's registers. */ void ! write_cp15_reg (ARMul_State * state, unsigned reg, unsigned opcode_2, unsigned CRm, ARMword value) { if (opcode_2) { *************** write_cp15_reg (unsigned reg, unsigned o *** 245,250 **** --- 246,260 ---- BITS (31, 14) and BIT (10) write as zero, BITS (6, 3) write as one. */ value &= 0x00003b87; value |= 0x00000078; + + /* Change the endianness if necessary */ + if ((value & ARMul_CP15_R1_ENDIAN) != + (XScale_cp15_opcode_2_is_0_Regs [reg] & ARMul_CP15_R1_ENDIAN)) + { + state->bigendSig = value & ARMul_CP15_R1_ENDIAN; + /* Force ARMulator to notice these now. */ + state->Emulate = CHANGEMODE; + } break; case 2: /* Translation Table Base. */ *************** write_cp15_reg (unsigned reg, unsigned o *** 324,332 **** return; } ! /* Return the value in a cp13 register. */ ! static ARMword read_cp15_reg (unsigned reg, unsigned opcode_2, unsigned CRm) { if (opcode_2 == 0) --- 334,342 ---- return; } ! /* Return the value in a cp15 register. */ ! ARMword read_cp15_reg (unsigned reg, unsigned opcode_2, unsigned CRm) { if (opcode_2 == 0) *************** XScale_cp15_LDC (ARMul_State * state, un *** 364,370 **** result = check_cp15_access (state, reg, 0, 0, 0); if (result == ARMul_DONE && type == ARMul_DATA) ! write_cp15_reg (reg, 0, 0, data); return result; } --- 374,380 ---- result = check_cp15_access (state, reg, 0, 0, 0); if (result == ARMul_DONE && type == ARMul_DATA) ! write_cp15_reg (state, reg, 0, 0, data); return result; } *************** XScale_cp15_MCR (ARMul_State * state, *** 416,422 **** result = check_cp15_access (state, reg, CRm, BITS (21, 23), opcode_2); if (result == ARMul_DONE) ! write_cp15_reg (reg, opcode_2, CRm, value); return result; } --- 426,432 ---- result = check_cp15_access (state, reg, CRm, BITS (21, 23), opcode_2); if (result == ARMul_DONE) ! write_cp15_reg (state, reg, opcode_2, CRm, value); return result; } *************** XScale_cp15_write_reg (ARMul_State * sta *** 440,450 **** { /* FIXME: Not sure what to do about the alternative register set here. For now default to just accessing CRm == 0 registers. */ ! write_cp15_reg (reg, 0, 0, value); return TRUE; } /* Coprocessor 13: Interrupt Controller and Bus Controller. */ /* There are two sets of registers for copro 13. --- 450,557 ---- { /* FIXME: Not sure what to do about the alternative register set here. For now default to just accessing CRm == 0 registers. */ ! write_cp15_reg (state, reg, 0, 0, value); return TRUE; } + /***************************************************************************\ + * Check for special XScale memory access features * + \***************************************************************************/ + void + XScale_check_memacc (ARMul_State * state, ARMword * address, int store) + { + ARMword dbcon, r0, r1; + int e1, e0; + + if (!state->is_XScale) + return; + + /* Check for PID-ification. + XXX BTB access support will require this test failing. */ + r0 = (read_cp15_reg (13, 0, 0) & 0xfe000000); + if (r0 && (*address & 0xfe000000) == 0) + *address |= r0; + + /* Check alignment fault enable/disable. */ + if ((read_cp15_reg (1, 0, 0) & ARMul_CP15_R1_ALIGN) && (*address & 3)) + ARMul_Abort (state, ARMul_DataAbortV); + + if (XScale_debug_moe (state, -1)) + return; + + /* Check the data breakpoint registers. */ + dbcon = read_cp15_reg (14, 0, 4); + r0 = read_cp15_reg (14, 0, 0); + r1 = read_cp15_reg (14, 0, 3); + e0 = dbcon & ARMul_CP15_DBCON_E0; + + if (dbcon & ARMul_CP15_DBCON_M) + { + /* r1 is a inverse mask. */ + if (e0 != 0 && ((store && e0 != 3) || (!store && e0 != 1)) + && ((*address & ~r1) == (r0 & ~r1))) + { + XScale_debug_moe (state, ARMul_CP14_R10_MOE_DB); + ARMul_OSHandleSWI (state, SWI_Breakpoint); + } + } + else + { + if (e0 != 0 && ((store && e0 != 3) || (!store && e0 != 1)) + && ((*address & ~3) == (r0 & ~3))) + { + XScale_debug_moe (state, ARMul_CP14_R10_MOE_DB); + ARMul_OSHandleSWI (state, SWI_Breakpoint); + } + + e1 = (dbcon & ARMul_CP15_DBCON_E1) >> 2; + if (e1 != 0 && ((store && e1 != 3) || (!store && e1 != 1)) + && ((*address & ~3) == (r1 & ~3))) + { + XScale_debug_moe (state, ARMul_CP14_R10_MOE_DB); + ARMul_OSHandleSWI (state, SWI_Breakpoint); + } + } + } + + /***************************************************************************\ + * Check set + \***************************************************************************/ + void + XScale_set_fsr_far(ARMul_State * state, ARMword fsr, ARMword far) + { + if (!state->is_XScale || (read_cp14_reg (10) & (1UL << 31)) == 0) + return; + + write_cp15_reg (state, 5, 0, 0, fsr); + write_cp15_reg (state, 6, 0, 0, far); + } + + /* Set the XScale debug `method of entry' if it is enabled. */ + int + XScale_debug_moe (ARMul_State * state, int moe) + { + ARMword value; + + if (!state->is_XScale) + return 1; + + value = read_cp14_reg (10); + if (value & (1UL << 31)) + { + if (moe != -1) + { + value &= ~0x1c; + value |= moe; + + write_cp14_reg (10, value); + } + return 1; + } + return 0; + } + /* Coprocessor 13: Interrupt Controller and Bus Controller. */ /* There are two sets of registers for copro 13. *************** write_cp14_reg (unsigned reg, ARMword va *** 734,739 **** --- 841,850 ---- case 0: /* PMNC */ /* Only BITS (27:12), BITS (10:8) and BITS (6:0) can be written. */ value &= 0x0ffff77f; + + /* Reset the clock counter if necessary */ + if (value & ARMul_CP14_R0_CLKRST) + XScale_cp14_Regs [1] = 0; break; case 4: Index: armdefs.h =================================================================== RCS file: /cvs/src/src/sim/arm/armdefs.h,v retrieving revision 1.7 diff -p -r1.7 armdefs.h *** armdefs.h 2000/11/30 01:55:12 1.7 --- armdefs.h 2001/01/10 05:18:21 *************** struct ARMul_State *** 102,107 **** --- 102,110 ---- ARMul_CPWrites *CPWrite[16]; /* Write CP register */ unsigned char *CPData[16]; /* Coprocessor data */ unsigned char const *CPRegWords[16]; /* map of coprocessor register sizes */ + unsigned long LastTime; /* Value of last call to ARMul_Time() */ + ARMword CP14R0_CCD; /* used to count 64 clock cycles with CP14 R0 bit + 3 set */ unsigned EventSet; /* the number of events in the queue */ unsigned long Now; /* time to the nearest cycle */ *************** extern ARMword ARMul_MemAccess (ARMul_St *** 339,344 **** --- 342,373 ---- #define ARMul_CANT 1 #define ARMul_INC 3 + #define ARMul_CP13_R0_FIQ 0x1 + #define ARMul_CP13_R0_IRQ 0x2 + #define ARMul_CP13_R8_PMUS 0x1 + + #define ARMul_CP14_R0_ENABLE 0x0001 + #define ARMul_CP14_R0_CLKRST 0x0004 + #define ARMul_CP14_R0_CCD 0x0008 + #define ARMul_CP14_R0_INTEN0 0x0010 + #define ARMul_CP14_R0_INTEN1 0x0020 + #define ARMul_CP14_R0_INTEN2 0x0040 + #define ARMul_CP14_R0_FLAG0 0x0100 + #define ARMul_CP14_R0_FLAG1 0x0200 + #define ARMul_CP14_R0_FLAG2 0x0400 + #define ARMul_CP14_R10_MOE_IB 0x0004 + #define ARMul_CP14_R10_MOE_DB 0x0008 + #define ARMul_CP14_R10_MOE_BT 0x000c + #define ARMul_CP15_R1_ENDIAN 0x0080 + #define ARMul_CP15_R1_ALIGN 0x0002 + #define ARMul_CP15_R5_X 0x0400 + #define ARMul_CP15_R5_ST_ALIGN 0x0001 + #define ARMul_CP15_R5_IMPRE 0x0406 + #define ARMul_CP15_R5_MMU_EXCPT 0x0400 + #define ARMul_CP15_DBCON_M 0x0100 + #define ARMul_CP15_DBCON_E1 0x000c + #define ARMul_CP15_DBCON_E0 0x0003 + extern unsigned ARMul_CoProInit (ARMul_State * state); extern void ARMul_CoProExit (ARMul_State * state); extern void ARMul_CoProAttach (ARMul_State * state, unsigned number, *************** extern void ARMul_CoProAttach (ARMul_Sta *** 348,353 **** --- 377,386 ---- ARMul_CDPs * cdp, ARMul_CPReads * read, ARMul_CPWrites * write); extern void ARMul_CoProDetach (ARMul_State * state, unsigned number); + extern void XScale_check_memacc (ARMul_State * state, ARMword * address, + int store); + extern void XScale_set_fsr_far (ARMul_State * state, ARMword fsr, ARMword far); + extern int XScale_debug_moe (ARMul_State * state, int moe); /***************************************************************************\ * Definitons of things in the host environment * Index: armemu.c =================================================================== RCS file: /cvs/src/src/sim/arm/armemu.c,v retrieving revision 1.17 diff -p -r1.17 armemu.c *** armemu.c 2000/12/19 00:58:04 1.17 --- armemu.c 2001/01/10 05:18:29 *************** extern int stop_simulator; *** 279,293 **** are being executed: */ ARMword isize; - #ifdef MODE32 ARMword ARMul_Emulate32 (register ARMul_State * state) - { #else - ARMword ARMul_Emulate26 (register ARMul_State * state) - { #endif register ARMword instr, /* the current instruction */ dest = 0, /* almost the DestBus */ temp, /* ubiquitous third hand */ --- 279,291 ---- are being executed: */ ARMword isize; ARMword + #ifdef MODE32 ARMul_Emulate32 (register ARMul_State * state) #else ARMul_Emulate26 (register ARMul_State * state) #endif + { register ARMword instr, /* the current instruction */ dest = 0, /* almost the DestBus */ temp, /* ubiquitous third hand */ *************** ARMul_Emulate26 (register ARMul_State * *** 531,536 **** --- 529,607 ---- break; } /* cc check */ + /* Handle the Clock counter here. */ + if (state->is_XScale) + { + ARMword cp14r0 = state->CPRead[14] (state, 0, 0); + + if (cp14r0 && ARMul_CP14_R0_ENABLE) + { + unsigned long newcycles, nowtime = ARMul_Time(state); + + newcycles = nowtime - state->LastTime; + state->LastTime = nowtime; + if (cp14r0 && ARMul_CP14_R0_CCD) + { + if (state->CP14R0_CCD == -1) + state->CP14R0_CCD = newcycles; + else + state->CP14R0_CCD += newcycles; + if (state->CP14R0_CCD >= 64) + { + newcycles = 0; + while (state->CP14R0_CCD >= 64) + state->CP14R0_CCD -= 64, newcycles++; + goto check_PMUintr; + } + } + else + { + ARMword cp14r1; + int do_int = 0; + + state->CP14R0_CCD = -1; + check_PMUintr: + cp14r0 |= ARMul_CP14_R0_FLAG2; + (void) state->CPWrite[14] (state, 0, cp14r0); + + cp14r1 = state->CPRead[14] (state, 1, 0); + + /* coded like this for portability */ + while (newcycles) + { + if (cp14r1 == 0xffffffff) + { + cp14r1 = 0; + do_int = 1; + } + else + cp14r1++; + newcycles--; + } + (void) state->CPWrite[14] (state, 1, cp14r1); + if (do_int && (cp14r0 & ARMul_CP14_R0_INTEN2)) + { + if (state->CPRead[13] (state, 8, 0) + && ARMul_CP13_R8_PMUS) + ARMul_Abort (state, ARMul_FIQV); + else + ARMul_Abort (state, ARMul_IRQV); + } + } + } + } + + /* Handle hardware instructions breakpoints here. */ + if (state->is_XScale) + { + if ((pc | 3) == (read_cp15_reg (14, 0, 8) | 2) + || (pc | 3) == (read_cp15_reg (14, 0, 9) | 2)) + { + if (XScale_debug_moe (state, ARMul_CP14_R10_MOE_IB)) + ARMul_OSHandleSWI (state, SWI_Breakpoint); + } + } + /***************************************************************************\ * Actual execution of instructions begins here * \***************************************************************************/ *************** ARMul_Emulate26 (register ARMul_State * *** 1356,1382 **** if (! SWI_vector_installed) ARMul_OSHandleSWI (state, SWI_Breakpoint); else ! ! /* BKPT - normally this will cause an abort, but for the ! XScale if bit 31 in register 10 of coprocessor 14 is ! clear, then this is treated as a no-op. */ ! if (state->is_XScale) ! { ! if (read_cp14_reg (10) & (1UL << 31)) ! { ! ARMword value; ! ! value = read_cp14_reg (10); ! value &= ~0x1c; ! value |= 0xc; ! ! write_cp14_reg (10, value); ! write_cp15_reg (5, 0, 0, 0x200); /* Set FSR. */ ! write_cp15_reg (6, 0, 0, pc); /* Set FAR. */ ! } ! else ! break; ! } ARMul_Abort (state, ARMul_PrefetchAbortV); break; --- 1427,1439 ---- if (! SWI_vector_installed) ARMul_OSHandleSWI (state, SWI_Breakpoint); else ! { ! /* BKPT - normally this will cause an abort, but on the ! XScale we must check the DCSR. */ ! XScale_set_fsr_far (state, ARMul_CP15_R5_MMU_EXCPT, pc); ! if (!XScale_debug_moe (state, ARMul_CP14_R10_MOE_BT)) ! break; ! } ARMul_Abort (state, ARMul_PrefetchAbortV); break; *************** ARMul_Emulate26 (register ARMul_State * *** 3427,3432 **** --- 3484,3490 ---- case 0xff: if (instr == ARMul_ABORTWORD && state->AbortAddr == pc) { /* a prefetch abort */ + XScale_set_fsr_far (state, ARMul_CP15_R5_MMU_EXCPT, pc); ARMul_Abort (state, ARMul_PrefetchAbortV); break; } *************** LoadMult (ARMul_State * state, ARMword i *** 4296,4302 **** if (!state->abortSig && !state->Aborted) state->Reg[temp++] = dest; else if (!state->Aborted) ! state->Aborted = ARMul_DataAbortV; for (; temp < 16; temp++) /* S cycles from here on */ if (BIT (temp)) --- 4354,4363 ---- if (!state->abortSig && !state->Aborted) state->Reg[temp++] = dest; else if (!state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } for (; temp < 16; temp++) /* S cycles from here on */ if (BIT (temp)) *************** LoadMult (ARMul_State * state, ARMword i *** 4306,4312 **** if (!state->abortSig && !state->Aborted) state->Reg[temp] = dest; else if (!state->Aborted) ! state->Aborted = ARMul_DataAbortV; } if (BIT (15) && !state->Aborted) --- 4367,4376 ---- if (!state->abortSig && !state->Aborted) state->Reg[temp] = dest; else if (!state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } } if (BIT (15) && !state->Aborted) *************** LoadSMult (ARMul_State * state, ARMword *** 4362,4368 **** if (!state->abortSig) state->Reg[temp++] = dest; else if (!state->Aborted) ! state->Aborted = ARMul_DataAbortV; for (; temp < 16; temp++) /* S cycles from here on */ if (BIT (temp)) --- 4426,4435 ---- if (!state->abortSig) state->Reg[temp++] = dest; else if (!state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } for (; temp < 16; temp++) /* S cycles from here on */ if (BIT (temp)) *************** LoadSMult (ARMul_State * state, ARMword *** 4372,4378 **** if (!state->abortSig && !state->Aborted) state->Reg[temp] = dest; else if (!state->Aborted) ! state->Aborted = ARMul_DataAbortV; } if (BIT (15) && !state->Aborted) --- 4439,4448 ---- if (!state->abortSig && !state->Aborted) state->Reg[temp] = dest; else if (!state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } } if (BIT (15) && !state->Aborted) *************** StoreMult (ARMul_State * state, ARMword *** 4464,4470 **** ARMul_StoreWordN (state, address, state->Reg[temp++]); #endif if (state->abortSig && !state->Aborted) ! state->Aborted = ARMul_DataAbortV; if (BIT (21) && LHSReg != 15) LSBase = WBBase; --- 4534,4543 ---- ARMul_StoreWordN (state, address, state->Reg[temp++]); #endif if (state->abortSig && !state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } if (BIT (21) && LHSReg != 15) LSBase = WBBase; *************** StoreMult (ARMul_State * state, ARMword *** 4475,4481 **** address += 4; ARMul_StoreWordS (state, address, state->Reg[temp]); if (state->abortSig && !state->Aborted) ! state->Aborted = ARMul_DataAbortV; } if (state->Aborted) { --- 4548,4557 ---- address += 4; ARMul_StoreWordS (state, address, state->Reg[temp]); if (state->abortSig && !state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } } if (state->Aborted) { *************** StoreSMult (ARMul_State * state, ARMword *** 4537,4543 **** ARMul_StoreWordN (state, address, state->Reg[temp++]); #endif if (state->abortSig && !state->Aborted) ! state->Aborted = ARMul_DataAbortV; if (BIT (21) && LHSReg != 15) LSBase = WBBase; --- 4613,4622 ---- ARMul_StoreWordN (state, address, state->Reg[temp++]); #endif if (state->abortSig && !state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } if (BIT (21) && LHSReg != 15) LSBase = WBBase; *************** StoreSMult (ARMul_State * state, ARMword *** 4548,4554 **** address += 4; ARMul_StoreWordS (state, address, state->Reg[temp]); if (state->abortSig && !state->Aborted) ! state->Aborted = ARMul_DataAbortV; } if (state->Mode != USER26MODE && state->Mode != USER32MODE) --- 4627,4636 ---- address += 4; ARMul_StoreWordS (state, address, state->Reg[temp]); if (state->abortSig && !state->Aborted) ! { ! XScale_set_fsr_far(state, ARMul_CP15_R5_ST_ALIGN, address); ! state->Aborted = ARMul_DataAbortV; ! } } if (state->Mode != USER26MODE && state->Mode != USER32MODE) Index: armemu.h =================================================================== RCS file: /cvs/src/src/sim/arm/armemu.h,v retrieving revision 1.10 diff -p -r1.10 armemu.h *** armemu.h 2000/11/30 01:55:12 1.10 --- armemu.h 2001/01/10 05:18:31 *************** extern void ARMul_CoProAttach (ARMul *** 490,495 **** ARMul_LDCs *, ARMul_STCs *, ARMul_MRCs *, ARMul_MCRs *, ARMul_CDPs *, ARMul_CPReads *, ARMul_CPWrites *); extern void ARMul_CoProDetach (ARMul_State *, unsigned); ! extern void write_cp15_reg (unsigned, unsigned, unsigned, ARMword); extern void write_cp14_reg (unsigned, ARMword); extern ARMword read_cp14_reg (unsigned); --- 490,495 ---- ARMul_LDCs *, ARMul_STCs *, ARMul_MRCs *, ARMul_MCRs *, ARMul_CDPs *, ARMul_CPReads *, ARMul_CPWrites *); extern void ARMul_CoProDetach (ARMul_State *, unsigned); ! extern void write_cp15_reg (ARMul_State *, unsigned, unsigned, unsigned, ARMword); extern void write_cp14_reg (unsigned, ARMword); extern ARMword read_cp14_reg (unsigned); Index: arminit.c =================================================================== RCS file: /cvs/src/src/sim/arm/arminit.c,v retrieving revision 1.6 diff -p -r1.6 arminit.c *** arminit.c 2000/11/30 01:55:12 1.6 --- arminit.c 2001/01/10 05:18:31 *************** ARMul_NewState (void) *** 106,111 **** --- 106,114 ---- state->OSptr = NULL; state->CommandLine = NULL; + state->CP14R0_CCD = -1; + state->LastTime = 0; + state->EventSet = 0; state->Now = 0; state->EventPtr = (struct EventNode **) malloc ((unsigned) EVENTLISTSIZE * *************** ARMul_Abort (ARMul_State * state, ARMwor *** 299,308 **** SETABORT (IBIT, SVC26MODE, isize); break; case ARMul_IRQV: /* IRQ */ ! SETABORT (IBIT, state->prog32Sig ? IRQ32MODE : IRQ26MODE, esize); break; case ARMul_FIQV: /* FIQ */ ! SETABORT (INTBITS, state->prog32Sig ? FIQ32MODE : FIQ26MODE, esize); break; } if (ARMul_MODE32BIT) --- 302,315 ---- SETABORT (IBIT, SVC26MODE, isize); break; case ARMul_IRQV: /* IRQ */ ! if (!state->is_XScale ! || (state->CPRead[13](state, 0, 0) & ARMul_CP13_R0_IRQ)) ! SETABORT (IBIT, state->prog32Sig ? IRQ32MODE : IRQ26MODE, esize); break; case ARMul_FIQV: /* FIQ */ ! if (!state->is_XScale ! || (state->CPRead[13](state, 0, 0) & ARMul_CP13_R0_FIQ)) ! SETABORT (INTBITS, state->prog32Sig ? FIQ32MODE : FIQ26MODE, esize); break; } if (ARMul_MODE32BIT) Index: armvirt.c =================================================================== RCS file: /cvs/src/src/sim/arm/armvirt.c,v retrieving revision 1.3 diff -p -r1.3 armvirt.c *** armvirt.c 2000/07/04 08:00:19 1.3 --- armvirt.c 2001/01/10 05:18:32 *************** freed as they might be needed again. A s *** 24,29 **** --- 24,30 ---- defined to generate aborts. */ #include "armopts.h" + #include "armos.h" #include "armdefs.h" #include "ansidecl.h" *************** GetWord (ARMul_State * state, ARMword ad *** 61,66 **** --- 62,69 ---- ARMword **pagetable; ARMword *pageptr; + XScale_check_memacc (state, &address, 0); + page = address >> PAGEBITS; offset = (address & OFFSETBITS) >> 2; pagetable = (ARMword **) state->MemDataPtr; *************** PutWord (ARMul_State * state, ARMword ad *** 93,98 **** --- 96,103 ---- ARMword offset; ARMword **pagetable; ARMword *pageptr; + + XScale_check_memacc (state, &address, 1); page = address >> PAGEBITS; offset = (address & OFFSETBITS) >> 2; >From ac131313@cygnus.com Fri Jan 12 01:20:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] implement putchar_filtered() Date: Fri, 12 Jan 2001 01:20:00 -0000 Message-id: <3A5ECBF2.C6FB0F33@cygnus.com> References: <200101032042.PAA14840@nog.bosbc.com> X-SW-Source: 2001-01/msg00073.html Content-length: 2016 Nicholas Duffek wrote: > > This patch adds putchar_filtered() to the collection of stdio-like > _filtered and _unfiltered functions in utils.c. > > ChangeLog: > > * defs.h (putchar_filtered): Prototype. > * utils.c (putchar_filtered): Define. FYI, As a general direction, *_filtered() and *_unfiltered() should go away. See the TODO file where it talks about: -- Re-do GDB's output pager. GDB's output pager still relies on people correctly using *_filtered for gdb_stdout and *_unfiltered for gdb_stdlog / gdb_stderr. Hopefully, with all normal output going to gdb_stdout, the pager can just look at the ui_file that the output is on and then use that to decide what to do about paging. Sounds good in theory. -- Things like the CLI should be fetching chunks of output and then sending them down the gdb_stdout et.al. stream. It is up to the stream (and not someones arbitrary choice of *_filtered) to determine if paging should occure. Andrew > No regressions on i686-pc-linux-gnu. Okay to apply? > > Nicholas Duffek > > > [patch follows] > > Index: gdb/defs.h > =================================================================== > diff -up gdb/defs.h gdb/defs.h > --- gdb/defs.h Tue Dec 19 11:13:25 2000 > +++ gdb/defs.h Tue Dec 19 11:13:09 2000 > @@ -446,6 +446,8 @@ extern int fputc_filtered (int c, struct > > extern int fputc_unfiltered (int c, struct ui_file *); > > +extern int putchar_filtered (int c); > + > extern int putchar_unfiltered (int c); > > extern void puts_filtered (const char *); > Index: gdb/utils.c > =================================================================== > diff -up gdb/utils.c gdb/utils.c > --- gdb/utils.c Tue Dec 19 11:13:48 2000 > +++ gdb/utils.c Tue Dec 19 11:13:09 2000 > @@ -1867,6 +1867,12 @@ putchar_unfiltered (int c) > } > > int > +putchar_filtered (int c) > +{ > + return fputc_filtered (c, gdb_stdout); > +} > + > +int > fputc_unfiltered (int c, struct ui_file *stream) > { > char buf = c; >From ac131313@cygnus.com Fri Jan 12 01:37:00 2001 From: Andrew Cagney To: David Taylor Cc: insight@sources.redhat.com, gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] insight gdb_stdlog bug Date: Fri, 12 Jan 2001 01:37:00 -0000 Message-id: <3A5ECFF0.26F10C8@cygnus.com> References: <200012202252.RAA28763@texas.cygnus.com> X-SW-Source: 2001-01/msg00074.html Content-length: 16611 David Taylor wrote: > > When GDBTK_TO_RESULT is set, insight gobbles all output written to > gdb_stdlog. But, the stuff written to gdb_stdlog isn't meant to be > parsed by insight -- it's meant to be read by a person. > > While it might be desired -- when GDBTK_TO_RESULT is not set -- that > gdb_stdlog go the same place as gdb_stdout, it cannot have the same > pointer value as gdb_stdout or the code won't be able to distinguish > output meant for gdb_stdout vs output meant for gdb_stdlog when > GDBTK_TO_RESULT is set. > > The following patch fixes that. (The result is that output written to > gdb_stdlog appears in the insight console window if it is active.) > > ChangeLog entries (3 separate ChangeLog files): > > * main.c (captured_main): Initialize gdb_stdlog to a copy of > gdb_stdout rather than to gdb_stdout, so that code can distinguish > them. > > * tui/tui-file.c (tui_file_fputs): Handle gdb_stdlog the same > as gdb_stdout. > > * gdbtk/generic/gdbtk-hooks.c (gdbtk_fputs): Distinguish between > gdb_stdlog and gdb_stdout. David, This feels wrong. Anything touching tui/tui-file.c is going in the wrong direction. Rather than depend on tui-file.c, gdbtk should, like mi, create its own *-file object and use that. The attatched (very old) patch does this. From memory, its poossible approval was lost in time. Andrew Index: ChangeLog-gdbtk =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/ChangeLog-gdbtk,v retrieving revision 2.113 diff -p -r2.113 ChangeLog-gdbtk *** ChangeLog-gdbtk 1999/06/21 20:12:40 2.113 --- ChangeLog-gdbtk 1999/06/25 07:34:29 *************** *** 1,3 **** --- 1,27 ---- + Wed May 26 10:37:25 1999 Andrew Cagney + + * gdbtk-hooks.c (gdbtk_fputs): Make static. + (gdbtk_add_hooks): Delete assignment of flush_hook. + (struct gdbtk_file): Dummy structure. + (gdbtk_file_delete, gdbtk_file_new): New functions. Implement + ``struct gdb_file'' for GDBtk. + (gdbtk_flush): Delete function. + + * gdbtk.h (gdbtk_claim_stdio, gdbtk_release_stdio, + gdbtk_null_stdio): Add declarations. + * gdbtk-hooks.c (gdbtk_claim_stdio, gdbtk_release_stdio, + gdbtk_null_stdio): New functions. Switch between output + alternatives. + + * gdbtk.c (gdbtk_fputs): Delete declaration. + (gdbtk_init): Replace assignment of fputs_unfiltered_hook with + calls to gdbtk_claim_stdio and gdbtk_release_stdio. + + * gdbtk-variable.c (create_variable): Call gdbtk_claim_stdio() to + restore GDBtk output. Call gdbtk_null_stdio() to discard the + output. + (variable_value_changed): Ditto. + 1999-06-21 James Ingham * gdbtk.c (target_should_use_timer): Add check for "linuxthreads" Index: gdbtk-hooks.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/gdbtk-hooks.c,v retrieving revision 2.25 diff -p -r2.25 gdbtk-hooks.c *** gdbtk-hooks.c 1999/06/15 19:24:18 2.25 --- gdbtk-hooks.c 1999/06/25 07:34:30 *************** static void gdbtk_warning PARAMS ((con *** 90,96 **** static char* gdbtk_readline PARAMS ((char *)); static void gdbtk_readline_begin (char *format, ...); static void gdbtk_readline_end PARAMS ((void)); - static void gdbtk_flush PARAMS ((GDB_FILE *)); static void gdbtk_pre_add_symbol PARAMS ((char *)); static void gdbtk_print_frame_info PARAMS ((struct symtab *, int, int, int)); static void gdbtk_post_add_symbol PARAMS ((void)); --- 90,95 ---- *************** static void gdbtk_error_begin PARAMS ((v *** 103,114 **** static void report_error (void); static void gdbtk_annotate_signal (void); ! /* ! * gdbtk_fputs can't be static, because we need to call it in gdbtk.c. ! * See note there for details. ! */ ! ! void gdbtk_fputs PARAMS ((const char *, GDB_FILE *)); int gdbtk_load_hash PARAMS ((char *, unsigned long)); static void breakpoint_notify PARAMS ((struct breakpoint *, const char *)); --- 102,108 ---- static void report_error (void); static void gdbtk_annotate_signal (void); ! static void gdbtk_fputs PARAMS ((const char *, GDB_FILE *)); int gdbtk_load_hash PARAMS ((char *, unsigned long)); static void breakpoint_notify PARAMS ((struct breakpoint *, const char *)); *************** gdbtk_add_hooks(void) *** 129,135 **** print_frame_info_listing_hook = gdbtk_print_frame_info; query_hook = gdbtk_query; warning_hook = gdbtk_warning; - flush_hook = gdbtk_flush; create_breakpoint_hook = gdbtk_create_breakpoint; delete_breakpoint_hook = gdbtk_delete_breakpoint; --- 123,128 ---- *************** gdbtk_add_hooks(void) *** 162,169 **** } /* These control where to put the gdb output which is created by ! {f}printf_{un}filtered and friends. gdbtk_fputs and gdbtk_flush are the ! lowest level of these routines and capture all output from the rest of GDB. The reason to use the result_ptr rather than the gdbtk_interp's result directly is so that a call_wrapper invoked function can preserve its result --- 155,163 ---- } /* These control where to put the gdb output which is created by ! {f}printf_{un}filtered and friends. gdbtk_fputs is the lowest ! level of these routines and capture all output from the rest of ! GDB. The reason to use the result_ptr rather than the gdbtk_interp's result directly is so that a call_wrapper invoked function can preserve its result *************** int gdbtk_two_elem_cmd (cmd_name, argv1) *** 205,221 **** return result; } - static void - gdbtk_flush (stream) - GDB_FILE *stream; - { - #if 0 - /* Force immediate screen update */ - - Tcl_VarEval (gdbtk_interp, "gdbtk_tcl_flush", NULL); - #endif - } - /* This handles all the output from gdb. All the gdb printf_xxx functions * eventually end up here. The output is either passed to the result_ptr * where it will go to the result of some gdbtk command, or passed to the --- 199,204 ---- *************** gdbtk_flush (stream) *** 236,246 **** * */ ! void gdbtk_fputs (ptr, stream) const char *ptr; GDB_FILE *stream; { in_fputs = 1; if (result_ptr != NULL) --- 219,238 ---- * */ ! static int gdbtk_file_magic; ! ! struct gdbtk_file ! { ! int *magic; ! }; ! ! static void gdbtk_fputs (ptr, stream) const char *ptr; GDB_FILE *stream; { + /* struct gdbtk_file *gdbtk = gdb_file_data (stream); */ + /* ASSERT (gdbtk_file->magic == &gdbtk_file_magic); */ in_fputs = 1; if (result_ptr != NULL) *************** gdbtk_fputs (ptr, stream) *** 276,281 **** --- 268,342 ---- } in_fputs = 0; + } + + static gdb_file_delete_ftype gdbtk_file_delete; + static void + gdbtk_file_delete (stream) + struct gdb_file *stream; + { + struct gdbtk_file *gdbtk = gdb_file_data (stream); + /* ASSERT (gdbtk_file->magic == &gdbtk_file_magic); */ + free (gdbtk); + } + + static struct gdb_file *gdbtk_file_new PARAMS ((void)); + static struct gdb_file * + gdbtk_file_new () + { + struct gdb_file *gdb_file = gdb_file_new (); + struct gdbtk_file *gdbtk_file = xmalloc (sizeof (struct gdbtk_file)); + gdbtk_file->magic = &gdbtk_file_magic; + set_gdb_file_fputs (gdb_file, gdbtk_fputs); + set_gdb_file_data (gdb_file, gdbtk_file, gdbtk_file_delete); + return gdb_file; + } + + static struct gdb_file *tty_stdout; + static struct gdb_file *tty_stderr; + + static struct gdb_file *gdbtk_stdout; + static struct gdb_file *gdbtk_stderr; + + static struct gdb_file *null_stdout; + static struct gdb_file *null_stderr; + + void + gdbtk_claim_stdio () + { + static int done; + if (!done) + { + /* save the original gdb_stdout/gdb_stderr. */ + tty_stdout = gdb_stdout; + tty_stderr = gdb_stderr; + /* create GDBtk's stdout/stderr. */ + gdbtk_stdout = gdbtk_file_new (); + gdbtk_stderr = gdbtk_file_new (); + /* and null devices */ + null_stdout = gdb_file_new (); + null_stderr = gdb_file_new (); + done = 1; + } + /* select our stdio */ + gdb_stdout = gdbtk_stdout; + gdb_stderr = gdbtk_stderr; + } + + void + gdbtk_release_stdio () + { + /* restore the original stdio. */ + gdb_stdout = tty_stdout; + gdb_stderr = tty_stderr; + } + + void + gdbtk_null_stdio () + { + /* null output */ + gdb_stdout = null_stdout; + gdb_stderr = null_stderr; } /* Index: gdbtk-variable.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/gdbtk-variable.c,v retrieving revision 2.7 diff -p -r2.7 gdbtk-variable.c *** gdbtk-variable.c 1999/05/25 19:06:14 2.7 --- gdbtk-variable.c 1999/06/25 07:34:34 *************** create_variable (name, real_name, frame) *** 546,553 **** /* Several of the GDB_* calls can cause messages to be displayed. We swallow those here, because we don't need them (the "value" command will show them). */ ! old_fputs = fputs_unfiltered_hook; ! fputs_unfiltered_hook = null_fputs; /* Parse and evaluate the expression, filling in as much of the variable's data as possible */ --- 546,552 ---- /* Several of the GDB_* calls can cause messages to be displayed. We swallow those here, because we don't need them (the "value" command will show them). */ ! gdbtk_null_stdio (); /* Parse and evaluate the expression, filling in as much of the variable's data as possible */ *************** create_variable (name, real_name, frame) *** 572,578 **** FREEIF ((char *) var); /* Restore the output hook to normal */ ! fputs_unfiltered_hook = old_fputs; return NULL; } --- 571,577 ---- FREEIF ((char *) var); /* Restore the output hook to normal */ ! gdbtk_claim_stdio (); return NULL; } *************** create_variable (name, real_name, frame) *** 584,590 **** FREEIF (var); /* Restore the output hook to normal */ ! fputs_unfiltered_hook = old_fputs; printf_unfiltered ("Attempt to use a type name as an expression."); return NULL; --- 583,589 ---- FREEIF (var); /* Restore the output hook to normal */ ! gdbtk_claim_stdio (); printf_unfiltered ("Attempt to use a type name as an expression."); return NULL; *************** create_variable (name, real_name, frame) *** 623,629 **** GDB_select_frame (old_fi, -1); /* Restore the output hook to normal */ ! fputs_unfiltered_hook = old_fputs; var->num_children = number_of_children (var); var->format = variable_default_display (var); --- 622,628 ---- GDB_select_frame (old_fi, -1); /* Restore the output hook to normal */ ! gdbtk_claim_stdio (); var->num_children = number_of_children (var); var->format = variable_default_display (var); *************** variable_value_changed (var) *** 1130,1137 **** /* evaluate_expression can output errors to the screen, so swallow them here. */ ! old_hook = fputs_unfiltered_hook; ! fputs_unfiltered_hook = null_fputs; /* Arrays, struct, classes, unions never change value */ if (type != NULL && (TYPE_CODE (type) == TYPE_CODE_STRUCT --- 1129,1135 ---- /* evaluate_expression can output errors to the screen, so swallow them here. */ ! gdbtk_null_stdio (); /* Arrays, struct, classes, unions never change value */ if (type != NULL && (TYPE_CODE (type) == TYPE_CODE_STRUCT *************** variable_value_changed (var) *** 1179,1185 **** } /* Restore the original fputs_hook. */ ! fputs_unfiltered_hook = old_hook; } /* Restore selected frame */ --- 1177,1183 ---- } /* Restore the original fputs_hook. */ ! gdbtk_claim_stdio (); } /* Restore selected frame */ *************** call_gdb_type_print (val) *** 1476,1483 **** int result; /* Save the old hook and install new hook */ ! old_hook = fputs_unfiltered_hook; ! fputs_unfiltered_hook = variable_fputs; /* Call our command with our args */ clear_gdb_output (); --- 1474,1480 ---- int result; /* Save the old hook and install new hook */ ! gdbtk_null_stdio (); /* Call our command with our args */ clear_gdb_output (); *************** call_gdb_type_print (val) *** 1489,1495 **** result = TCL_ERROR; /* Restore fputs hook */ ! fputs_unfiltered_hook = old_hook; return result; } --- 1486,1492 ---- result = TCL_ERROR; /* Restore fputs hook */ ! gdbtk_claim_stdio (); return result; } *************** call_gdb_val_print (val, format) *** 1505,1512 **** int result; /* Save the old hook and install new hook */ ! old_hook = fputs_unfiltered_hook; ! fputs_unfiltered_hook = variable_fputs; /* Call our command with our args */ clear_gdb_output (); --- 1502,1508 ---- int result; /* Save the old hook and install new hook */ ! gdbtk_null_stdio (); /* Call our command with our args */ clear_gdb_output (); *************** call_gdb_val_print (val, format) *** 1516,1522 **** r = GDB_value_fetch_lazy (val); if (r != GDB_OK) { ! fputs_unfiltered_hook = old_hook; return TCL_ERROR; } } --- 1512,1518 ---- r = GDB_value_fetch_lazy (val); if (r != GDB_OK) { ! gdbtk_claim_stdio (); return TCL_ERROR; } } *************** call_gdb_val_print (val, format) *** 1528,1534 **** result = TCL_ERROR; /* Restore fputs hook */ ! fputs_unfiltered_hook = old_hook; return result; } --- 1524,1530 ---- result = TCL_ERROR; /* Restore fputs hook */ ! gdbtk_claim_stdio (); return result; } Index: gdbtk.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/gdbtk.c,v retrieving revision 2.135 diff -p -r2.135 gdbtk.c *** gdbtk.c 1999/06/21 20:12:37 2.135 --- gdbtk.c 1999/06/25 07:34:35 *************** void gdbtk_add_hooks PARAMS ((void)); *** 112,125 **** int gdbtk_test PARAMS ((char *)); - /* - * gdbtk_fputs is defined in the gdbtk_hooks.c, but we need it here - * because we delay adding this hook till all the setup is done. That - * way errors will go to stdout. - */ - - extern void gdbtk_fputs PARAMS ((const char *, GDB_FILE *)); - /* Handle for TCL interpreter */ Tcl_Interp *gdbtk_interp = NULL; --- 112,117 ---- *************** gdbtk_find_main"; *** 525,531 **** /* fputs_unfiltered_hook = NULL; */ /* Force errors to stdout/stderr */ ! fputs_unfiltered_hook = gdbtk_fputs; if (Tcl_GlobalEval (gdbtk_interp, (char *) script) != TCL_OK) { --- 517,524 ---- /* fputs_unfiltered_hook = NULL; */ /* Force errors to stdout/stderr */ ! /* create custom GDBtk streams. */ ! gdbtk_claim_stdio (); if (Tcl_GlobalEval (gdbtk_interp, (char *) script) != TCL_OK) { *************** gdbtk_find_main"; *** 536,542 **** msg = Tcl_GetVar (gdbtk_interp, "errorInfo", TCL_GLOBAL_ONLY); ! fputs_unfiltered_hook = NULL; /* Force errors to stdout/stderr */ #ifdef _WIN32 MessageBox (NULL, msg, NULL, MB_OK | MB_ICONERROR | MB_TASKMODAL); --- 529,535 ---- msg = Tcl_GetVar (gdbtk_interp, "errorInfo", TCL_GLOBAL_ONLY); ! gdbtk_release_stdio (); /* Force errors to stdout/stderr */ #ifdef _WIN32 MessageBox (NULL, msg, NULL, MB_OK | MB_ICONERROR | MB_TASKMODAL); Index: gdbtk.h =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/gdbtk.h,v retrieving revision 2.8 diff -p -r2.8 gdbtk.h *** gdbtk.h 1999/04/02 18:33:13 2.8 --- gdbtk.h 1999/06/25 07:34:35 *************** extern int x_event PARAMS ((int)); *** 149,154 **** --- 149,159 ---- extern int gdbtk_two_elem_cmd PARAMS ((char *, char *)); extern int call_wrapper PARAMS ((ClientData, Tcl_Interp *, int, Tcl_Obj *CONST [])); + /* GDBtk stdio control functions. */ + extern void gdbtk_claim_stdio PARAMS ((void)); + extern void gdbtk_release_stdio PARAMS ((void)); + extern void gdbtk_null_stdio PARAMS ((void)); + #ifdef _WIN32 extern void close_bfds (); #endif /* _WIN32 */ >From ac131313@cygnus.com Fri Jan 12 01:40:00 2001 From: Andrew Cagney To: "Chris G. Demetriou" , GDB Patches Subject: Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen Date: Fri, 12 Jan 2001 01:40:00 -0000 Message-id: <3A5ED09C.95B1CE17@cygnus.com> References: <5telznaixe.fsf@highland.sibyte.com> X-SW-Source: 2001-01/msg00075.html Content-length: 296 [Ah, summer and holidays...] Chris, could you please add yourself and my self to sim/MAINTAINERS as mips sim maintainers. I'll next go through each of the patches (but they should be ok). Once the backlog is cleared, we can probably start using a much simpler self-approval process. Andrew >From ac131313@cygnus.com Fri Jan 12 01:45:00 2001 From: Andrew Cagney To: Fernando Nasser Cc: gdb-patches@sources.redhat.com Subject: [patch] Fix Value returned is ...; Was: RFA: [configure.in] Turn on UI_OUT code Date: Fri, 12 Jan 2001 01:45:00 -0000 Message-id: <3A5ED1BF.E543594E@cygnus.com> References: <3A35283C.A77EC44D@cygnus.com> <3A40A999.685C1A62@cygnus.com> <3A4125C2.F4E4A35@cygnus.com> X-SW-Source: 2001-01/msg00076.html Content-length: 2485 FYI, I've checked in the attatched. The UI had a subtle change in output. Andrew Fri Jan 12 18:29:46 2001 Andrew Cagney * infcmd.c (print_return_value): Restore space lost by switch to UIOUT. ``$NN='' should be ``$NN =''. Fri Jan 12 18:29:01 2001 Andrew Cagney * gdb.base/callfuncs.exp: Add space after ``Value returned is''. Index: infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.14 diff -p -r1.14 infcmd.c *** infcmd.c 2000/12/15 01:01:47 1.14 --- infcmd.c 2001/01/12 09:41:12 *************** print_return_value (int structure_return *** 1017,1023 **** stb = ui_out_stream_new (uiout); ui_out_text (uiout, "Value returned is "); ui_out_field_fmt (uiout, "gdb-result-var", "$%d", record_latest_value (value)); ! ui_out_text (uiout, "= "); value_print (value, stb->stream, 0, Val_no_prettyprint); ui_out_field_stream (uiout, "return-value", stb); ui_out_text (uiout, "\n"); --- 1017,1023 ---- stb = ui_out_stream_new (uiout); ui_out_text (uiout, "Value returned is "); ui_out_field_fmt (uiout, "gdb-result-var", "$%d", record_latest_value (value)); ! ui_out_text (uiout, " = "); value_print (value, stb->stream, 0, Val_no_prettyprint); ui_out_field_stream (uiout, "return-value", stb); ui_out_text (uiout, "\n"); Index: testsuite/gdb.base/callfuncs.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/callfuncs.exp,v retrieving revision 1.2 diff -p -r1.2 callfuncs.exp *** callfuncs.exp 2000/11/06 20:38:02 1.2 --- callfuncs.exp 2001/01/12 09:41:39 *************** if ![gdb_test "bt 2" \ *** 334,340 **** # make sure we are back at main and still have the same register contents. gdb_test "print add(4,5)" "The program being debugged stopped while.*" "" gdb_test "finish" \ ! "Value returned is.* = 9" \ "finish from call dummy breakpoint returns correct value" if ![gdb_test "bt 2" \ "#0 main.*" \ --- 334,340 ---- # make sure we are back at main and still have the same register contents. gdb_test "print add(4,5)" "The program being debugged stopped while.*" "" gdb_test "finish" \ ! "Value returned is .* = 9" \ "finish from call dummy breakpoint returns correct value" if ![gdb_test "bt 2" \ "#0 main.*" \ >From ac131313@cygnus.com Fri Jan 12 01:51:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] spelling corrections Date: Fri, 12 Jan 2001 01:51:00 -0000 Message-id: <3A5ED35A.B41E9304@cygnus.com> References: <200101032042.PAA14842@nog.bosbc.com> X-SW-Source: 2001-01/msg00077.html Content-length: 1704 yes. Nicholas Duffek wrote: > > This patch fixes a couple of miscellaneous spelling errors. > > ChangeLog: > > * blockframe.c (generic_get_saved_register): Spelling fix. > * frame.h (FRAME_FP): Spelling fix. > > Okay to apply? > > Nicholas Duffek > > > [patch follows] > > Index: gdb/blockframe.c > =================================================================== > diff -up gdb/blockframe.c gdb/blockframe.c > --- gdb/blockframe.c Tue Dec 19 11:05:37 2000 > +++ gdb/blockframe.c Tue Dec 19 11:05:09 2000 > @@ -1249,7 +1249,7 @@ generic_fix_call_dummy (char *dummy, COR > calculated rather than fetched). We will use not_lval for values > fetched from generic dummy frames. > > - Set *ADDRP to the address, either in memory on as a REGISTER_BYTE > + Set *ADDRP to the address, either in memory or as a REGISTER_BYTE > offset into the registers array. If the value is stored in a dummy > frame, set *ADDRP to zero. > > Index: gdb/frame.h > =================================================================== > diff -up gdb/frame.h gdb/frame.h > --- gdb/frame.h Tue Dec 19 11:05:43 2000 > +++ gdb/frame.h Tue Dec 19 11:05:09 2000 > @@ -121,7 +121,7 @@ enum print_what > extern void *frame_obstack_alloc (unsigned long size); > extern void frame_saved_regs_zalloc (struct frame_info *); > > -/* Return the frame address from FR. Except in the machine-dependent > +/* Return the frame address from FI. Except in the machine-dependent > *FRAME* macros, a frame address has no defined meaning other than > as a magic cookie which identifies a frame over calls to the > inferior. The only known exception is inferior.h >From ac131313@cygnus.com Fri Jan 12 01:56:00 2001 From: Andrew Cagney To: Fernando Nasser Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: [complaints.c] Use warning_hook Date: Fri, 12 Jan 2001 01:56:00 -0000 Message-id: <3A5ED463.24468679@cygnus.com> References: <3A36A6A8.7709A82A@cygnus.com> <3A40AAA9.34FE072B@cygnus.com> <3A40D9A9.3BA26980@cygnus.com> X-SW-Source: 2001-01/msg00078.html Content-length: 445 Fernando Nasser wrote: > The problem is: who will look for the *_hook functions in a -events file > (as opposed to a -hooks file)? > Thanks God there is grep and SourceNavigator :-) In hindsight, calling the file gdb-events.[hc] was a dumb decision (made by me :-). It should probably be re-named. One of the reasons it is dumb is that the word ``event'' in GDB has many meanings - people will take it to be a target program event. Andrew >From ac131313@cygnus.com Fri Jan 12 04:14:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] gdbarch.sh: document REGISTER_SIZE and REGISTER_BYTES Date: Fri, 12 Jan 2001 04:14:00 -0000 Message-id: <3A5EF4D0.C838379@cygnus.com> References: <200101032041.PAA14834@nog.bosbc.com> X-SW-Source: 2001-01/msg00079.html Content-length: 2438 Nicholas Duffek wrote: > > This patch adds comments documenting REGISTER_SIZE and REGISTER_BYTES in > gdbarch.sh. > > ChangeLog: > > * gdbarch.sh (REGISTER_SIZE, REGISTER_BYTES): Document. > * gdbarch.h: Regenerate. > > Okay to apply? > > Nicholas Duffek > > > [patch follows] > > Index: gdb/gdbarch.sh > =================================================================== > diff -up gdb/gdbarch.sh gdb/gdbarch.sh > --- gdb/gdbarch.sh Tue Jan 2 16:03:15 2001 > +++ gdb/gdbarch.sh Tue Jan 2 16:02:42 2001 > @@ -383,7 +383,10 @@ f:2:DWARF_REG_TO_REGNUM:int:dwarf_reg_to > f:2:SDB_REG_TO_REGNUM:int:sdb_reg_to_regnum:int sdb_regnr:sdb_regnr:::no_op_reg_to_regnum::0 > f:2:DWARF2_REG_TO_REGNUM:int:dwarf2_reg_to_regnum:int dwarf2_regnr:dwarf2_regnr:::no_op_reg_to_regnum::0 > f:2:REGISTER_NAME:char *:register_name:int regnr:regnr:::legacy_register_name::0 > +# Size of an instruction. At a guess you've been looking at that that really bizare code in valops.c and breakpoint.c where GDB uses register_size and byte swapping to create the call sequence for a dummy frame. /* CALL_DUMMY is an array of words (REGISTER_SIZE), but each word is in host byte order. Before calling FIX_CALL_DUMMY, we byteswap it and remove any extra bytes which might exist because ULONGEST is bigger than REGISTER_SIZE. NOTE: This is pretty wierd, as the call dummy is actually a sequence of instructions. But CISC machines will have to pack the instructions into REGISTER_SIZE units (and so will RISC machines for which INSTRUCTION_SIZE is not REGISTER_SIZE). NOTE: This is pretty stupid. CALL_DUMMY should be in strict target byte order. */ REGISTER_SIZE isn't an instruction size - take a look at the VAX. It is the size of an arbitrarially selected register. As GDBINT.texinfo mentions: @item CALL_DUMMY_WORDS .... Should be deprecated in favour of a macro that uses target-byte-ordered data. > v:2:REGISTER_SIZE:int:register_size::::0:-1 > +# Total number of bytes needed to store raw registers, including > +# pseudo-registers. Given that pseudo-register values are created using a fuction and raw register data, do they have any storage? > v:2:REGISTER_BYTES:int:register_bytes::::0:-1 > f:2:REGISTER_BYTE:int:register_byte:int reg_nr:reg_nr::0:0 > f:2:REGISTER_RAW_SIZE:int:register_raw_size:int reg_nr:reg_nr::0:0 Andrew >From ac131313@cygnus.com Fri Jan 12 04:18:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] gdbarch.sh: multi-arch PARM_BOUNDARY Date: Fri, 12 Jan 2001 04:18:00 -0000 Message-id: <3A5EF5A4.7C7EF047@cygnus.com> References: <200101032042.PAA14838@nog.bosbc.com> X-SW-Source: 2001-01/msg00080.html Content-length: 1262 Nick, This is a new architecture method. Can you explain its intended purpose. Andrew PS: Don't forget doc/gdbint.* PPS: You just need to post the gdbarch.sh diff :-) Nicholas Duffek wrote: > > ChangeLog: > > * gdbarch.sh (PARM_BOUNDARY): Define. > * gdbarch.c: Regenerate. > * gdbarch.h: Regenerate. > > No regressions on i686-pc-linux-gnu. Okay to apply? > > Nicholas Duffek > > > [patch follows] > > Index: gdb/gdbarch.sh > =================================================================== > diff -up gdb/gdbarch.sh gdb/gdbarch.sh > --- gdb/gdbarch.sh Tue Jan 2 16:04:32 2001 > +++ gdb/gdbarch.sh Tue Jan 2 16:03:56 2001 > @@ -480,6 +480,7 @@ F:2:STACK_ALIGN:CORE_ADDR:stack_align:CO > v:1:EXTRA_STACK_ALIGNMENT_NEEDED:int:extra_stack_alignment_needed::::0:1::0::: > F:2:REG_STRUCT_HAS_ADDR:int:reg_struct_has_addr:int gcc_p, struct type *type:gcc_p, type::0:0 > F:2:SAVE_DUMMY_FRAME_TOS:void:save_dummy_frame_tos:CORE_ADDR sp:sp::0:0 > +v:2:PARM_BOUNDARY:int:parm_boundary > # > v:2:TARGET_FLOAT_FORMAT:const struct floatformat *:float_format::::::default_float_format (gdbarch) > v:2:TARGET_DOUBLE_FORMAT:const struct floatformat *:double_format::::::default_double_format (gdbarch) >From ac131313@cygnus.com Fri Jan 12 04:20:00 2001 From: Andrew Cagney To: "Frank Ch. Eigler" Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Update copyright notice. Date: Fri, 12 Jan 2001 04:20:00 -0000 Message-id: <3A5EF623.A09706C2@cygnus.com> References: <200101022036.MAA10155@cleaver.cygnus.com> X-SW-Source: 2001-01/msg00081.html Content-length: 382 "Frank Ch. Eigler" wrote: > > msnyder wrote: > > : ! Copyright 1986, 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997, > : ! 1998, 1999, 2000, 2001 Free Software Foundation, Inc. > > Will the decree that requires this eyesore instead of the equivalent > > # ! Copyright 1986-1987, 1989, 1991-2001 Free Software Foundation, Inc. > > ever be lifted? No. Never.... >From ac131313@cygnus.com Fri Jan 12 04:32:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] new BASEREG_ADDRESS macro Date: Fri, 12 Jan 2001 04:32:00 -0000 Message-id: <3A5EF913.DD51B9E2@cygnus.com> References: <200101032041.PAA14830@nog.bosbc.com> X-SW-Source: 2001-01/msg00082.html Content-length: 1304 Nicholas Duffek wrote: > > Recently I worked on an architecture in which the stack pointer, frame > pointer, and addresses in other address registers are relative to an > offset stored in a special register. > > Consequently, when GDB uses an address in one of those registers, e.g. to > read a LOC_BASEREG symbol's value, the address must be modified by the > offset address. > > This patch introduces a new multi-arch macro, BASEREG_ADDRESS(addr), which > gives targets the opportunity to adjust addresses retrieved from > SYMBOL_BASEREG(var) registers. > > The default value for BASEREG_ADDRESS is core_addr_identity(addr), a new > function that returns its argument unchanged. Can you think of a name other than BASEREG_ADDRESS() that better reflects the transformation being performed? Have a look through gdbint for ideas. Reading the code: get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var), NULL); addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG (var))); + addr = BASEREG_ADDRESS (addr); addr += SYMBOL_VALUE (var); break; } my first guess was that BASEREG_ADDRESS returns the address of the register BASE in, at or near ``addr''. It also needs a gdbint.texi entry. enjoy, Andrew >From ac131313@cygnus.com Fri Jan 12 04:35:00 2001 From: Andrew Cagney To: David Taylor Cc: gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: David Taylor: [RFA] insight gdb_stdlog bug Date: Fri, 12 Jan 2001 04:35:00 -0000 Message-id: <3A5EF9C2.DB931EC6@cygnus.com> References: <200101021917.OAA01413@texas.cygnus.com> X-SW-Source: 2001-01/msg00083.html Content-length: 188 David Taylor wrote: > > Just a ping -- I never saw a response to this. To be fair, it is the summer holidays. Everyone is down the beach working on that new skin tumor ... :-) Andrew >From ac131313@cygnus.com Fri Jan 12 04:40:00 2001 From: Andrew Cagney To: Nick Duffek Cc: msnyder@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] Functionalize registers[] and register_valid[] Date: Fri, 12 Jan 2001 04:40:00 -0000 Message-id: <3A5EFADB.4A9DBF99@cygnus.com> References: <3A5392F6.8589BA32@redhat.com> <200101032118.f03LIrr02904@rtl.cygnus.com> X-SW-Source: 2001-01/msg00084.html Content-length: 443 Nick Duffek wrote: > > On 3-Jan-2001, Michael Snyder wrote: > > >Based on your description, I say go for it. > > Thanks. > > Since this and the other regcache.c patch are so large and touch such a > fundamental piece of GDB, I'll commit them after a 2-day waiting period. Nick, just FYI. 2-days in the middle of the summer holidays is kind of pushing it. Jumbo patches are best left on the table for a little longer than that. Andrew >From ac131313@cygnus.com Fri Jan 12 05:43:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Fri, 12 Jan 2001 05:43:00 -0000 Message-id: <3A5F09B3.93555F06@cygnus.com> References: <200101032042.PAA14850@nog.bosbc.com> X-SW-Source: 2001-01/msg00085.html Content-length: 264 Hick, At a guess the cli/* change is independant of the file reg.c. Is this correct? Assuming it is it should go in per fixes from Fernando and (private) notes from me. If it isn't independant then I'm interested in understanding the interdependency. Andrew >From fnasser@redhat.com Fri Jan 12 06:08:00 2001 From: Fernando Nasser To: Andrew Cagney Cc: Nicholas Duffek , gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Fri, 12 Jan 2001 06:08:00 -0000 Message-id: <3A5F0F8C.8927218@redhat.com> References: <200101032042.PAA14850@nog.bosbc.com> <3A5F09B3.93555F06@cygnus.com> X-SW-Source: 2001-01/msg00086.html Content-length: 774 Andrew Cagney wrote: > > Hick, > > At a guess the cli/* change is independant of the file reg.c. Is this > correct? Assuming it is it should go in per fixes from Fernando and > (private) notes from me. > > If it isn't independant then I'm interested in understanding the > interdependency. > I can answer that for Nick (I have already approved the cli part). Nick was actually the first developer to actualy separate the user interface part (adding it to the cli) and the core gdblib functionality. His cli code uses gdblib to get the data and them formats it for being pretty printed on the screen. Regards, Fernando -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From ac131313@cygnus.com Fri Jan 12 06:50:00 2001 From: Andrew Cagney To: Nicholas Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Fri, 12 Jan 2001 06:50:00 -0000 Message-id: <3A5F195D.90E4915@cygnus.com> References: <200101032042.PAA14850@nog.bosbc.com> X-SW-Source: 2001-01/msg00087.html Content-length: 1471 Nick, I'm afraid my response is a little hairy fairy and involves some hand waving :-( Looking through reg.[ch] I don't have any problems with it as a utility that some targets can use to implement their register buffer. What concerns me is that the code is widening the gdbarch interface so that it accomodates a specific reg-cache implementation. I know your code (unfortunatly) won't handle every case (new more bizare cases turn up every day) so I think it would be better for a generic-reg.c to focus on the common case and let the more esoteric architectures be handled on a per-architecture basis. Instead of pushing your implementation of the reg-cache up into the gdbarch vector (the REGISTER_LIST method) I think things should be tweeked so that your register implementation is pushed down a level. Over time, the interface can be abstracted/simplified further and more pushed into your and the old reg modules. Looking at one of the functions: real_register (int regnum) { - return regnum >= 0 && regnum < NUM_REGS; + if (REGISTER_LIST) + return regs_real (regnum); + else + return regnum >= 0 && regnum < NUM_REGS; } I think these should be made virtual so that your, or any other, code can just drop in.. ---- Did you get VALUE_REGNO() -> VALUE_REGNUM() in that rename? ---- The code doesn't appear to help how GDB handles register values in expressions and assignments (grep for VALUE_REGNO). Have you thought about that? Andrew >From msnyder@redhat.com Fri Jan 12 10:04:00 2001 From: Michael Snyder To: Andrew Cagney Cc: Nicholas Duffek , gdb-patches@sources.redhat.com Subject: Re: [RFA] gdbarch.sh: document REGISTER_SIZE and REGISTER_BYTES Date: Fri, 12 Jan 2001 10:04:00 -0000 Message-id: <3A5F46B6.216D@redhat.com> References: <200101032041.PAA14834@nog.bosbc.com> <3A5EF4D0.C838379@cygnus.com> X-SW-Source: 2001-01/msg00088.html Content-length: 530 Andrew Cagney wrote: > Given that pseudo-register values are created using a fuction and raw > register data, do they have any storage? Sometimes yes, sometimes no. A pseudo-register can be just an alias for another register, in which case it can share storage. But it can also be a computed value, in which case it may have its own storage. I had one case in which a pseudo-register was the concatenation of two regular registers -- but they weren't consecutive, so I had to give the pseudo its own storage and copy them. >From msnyder@redhat.com Fri Jan 12 10:06:00 2001 From: Michael Snyder To: Andrew Cagney Cc: Nick Duffek , gdb-patches@sources.redhat.com Subject: Re: [RFA] Functionalize registers[] and register_valid[] Date: Fri, 12 Jan 2001 10:06:00 -0000 Message-id: <3A5F471F.566C@redhat.com> References: <3A5392F6.8589BA32@redhat.com> <200101032118.f03LIrr02904@rtl.cygnus.com> <3A5EFADB.4A9DBF99@cygnus.com> X-SW-Source: 2001-01/msg00089.html Content-length: 284 Andrew Cagney wrote: > Nick, just FYI. > > 2-days in the middle of the summer holidays is kind of pushing it. > Jumbo patches are best left on the table for a little longer than that. OK, ok, we get the point -- it's summer where you are. Rub it in some more, why don't you? ;-) >From fche@redhat.com Fri Jan 12 10:49:00 2001 From: fche@redhat.com (Frank Ch. Eigler) To: cgd@sibyte.com (Chris G. Demetriou) Cc: gdb-patches@sourceware.cygnus.com Subject: Re: trivial fix to sim/common/aclocal.m4 SIM_AC_OPTION_SCACHE Date: Fri, 12 Jan 2001 10:49:00 -0000 Message-id: References: <5tvgt2peyi.fsf@highland.sibyte.com> X-SW-Source: 2001-01/msg00090.html Content-length: 600 cgd@sibyte.com (Chris G. Demetriou) wrote, way back when: : While looking through and cleaning our diffs to the sim bits, I : noticed a bug in SIM_AC_OPTION_SCACHE, a patch for which is below. : [...] : 2000-12-02 Chris Demetriou : : * aclocal.m4 (SIM_AC_OPTION_SCACHE): Properly : handle the case where a numeric value is supplied. Right - thanks! (Sorry it took so long.) : The existing code is obviously broken and the new code correct. [...] I would say that this patch is the kind directly committable by a contributor under the "obvious bug fix" principle. - FChE >From jingham@apple.com Fri Jan 12 11:35:00 2001 From: Jim Ingham To: gdb-patches@sources.redhat.com Subject: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 12 Jan 2001 11:35:00 -0000 Message-id: <200101121935.LAA03678@scv2.apple.com> X-SW-Source: 2001-01/msg00091.html Content-length: 1819 Hi, all, The following patch fixes an infinite recursion in the variable lookup code for C++ objects that are specified in mangled form. The old code would take the mangled name into lookup_symbol, unmangle it, and then in this bit pass the mangled name BACK to lookup_symbol, which would unmangle it and come right back here... Not a good thing. The bug crept in when lookup_symbol was broken up into lookup_symbol and lookup_symbol_aux, the correction is clearly what was meant. 2001-01-09 James Ingham * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to lookup a mangled symbol rather than recursing into lookup_symbol, since this will just re-unmangle the name & call lookup_symbol_aux - leading to an infinite recursion. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.15 diff -c -w -r1.15 symtab.c *** symtab.c 2000/09/04 08:29:25 1.15 --- symtab.c 2001/01/12 19:29:21 *************** *** 754,760 **** { /* This is a mangled variable, look it up by its mangled name. */ ! return lookup_symbol (SYMBOL_NAME (msymbol), block, namespace, is_a_field_of_this, symtab); } /* There are no debug symbols for this file, or we are looking --- 754,760 ---- { /* This is a mangled variable, look it up by its mangled name. */ ! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block, namespace, is_a_field_of_this, symtab); } /* There are no debug symbols for this file, or we are looking >From dberlin@redhat.com Fri Jan 12 12:10:00 2001 From: Daniel Berlin To: Jim Ingham Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Fri, 12 Jan 2001 12:10:00 -0000 Message-id: References: <200101121935.LAA03678@scv2.apple.com> X-SW-Source: 2001-01/msg00092.html Content-length: 863 On Fri, 12 Jan 2001, Jim Ingham wrote: > Hi, all, > > The following patch fixes an infinite recursion in the variable lookup > code for C++ objects that are specified in mangled form. The old code > would take the mangled name into lookup_symbol, unmangle it, and then in > this bit pass the mangled name BACK to lookup_symbol, which would > unmangle it and come right back here... Not a good thing. The bug > crept in when lookup_symbol was broken up into lookup_symbol and > lookup_symbol_aux, the correction is clearly what was meant. This was already known, and we are still waiting for Jim Blandy to make a decision whether we should revert the binary searching symbol lookup for C++ stuff or not. If we decide to stay with the non-linear symbol lookup, i'll fix the bugs, as i already have patches for most of them (there aren't many). --Dan