* Re: [RFA] New register definition interface
[not found] <200101032042.PAA14850@nog.bosbc.com>
@ 2001-01-05 11:56 ` Stephane Carrez
2001-01-13 18:22 ` Andrew Cagney
1 sibling, 0 replies; 2+ messages in thread
From: Stephane Carrez @ 2001-01-05 11:56 UTC (permalink / raw)
To: Nicholas Duffek; +Cc: gdb-patches
Hi All and Happy new Millenium!
Nicholas Duffek <nsd@redhat.com> 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 <nsd@redhat.com>
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" <eliz@is.elta.co.il>
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: <Pine.LNX.4.10.10101051339290.27907-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00055.html
Content-length: 1371
> Date: Fri, 5 Jan 2001 13:46:27 -0500 (EST)
> From: Daniel Berlin <dan@redhat.com>
>
> 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 <cgf@redhat.com>
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: <Pine.LNX.4.10.10101051339290.27907-100000@www.cgsoftware.com> <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 <msokolov@ivan.Harhan.ORG>
* 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 <cgf@redhat.com>
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 <fnasser@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
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 <cgf@redhat.com> 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 <cgf@redhat.com>
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 <nsd@redhat.com>
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 <nsd@redhat.com>
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
<nsd@redhat.com>
[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 <nsd@redhat.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 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 <nsd@redhat.com> 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 <nsd@redhat.com>
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 <nsd@redhat.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 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 <nsd@redhat.com> 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 <nsd@redhat.com>
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 <dsmith@redhat.com>
To: Nick Duffek <nsd@redhat.com>
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 <nsd@redhat.com>
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 <jtc@redback.com> 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 <nickc@redhat.com>
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 <nickc@redhat.com>
* 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 <mrg@cygnus.com>
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 <mrg@redhat.com>
* 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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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
> <nsd@redhat.com>
>
> [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 <ac131313@cygnus.com>
To: David Taylor <taylor@cygnus.com>
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 <cagney@b1.cygnus.com>
+
+ * 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 <jingham@leda.cygnus.com>
* 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 <ac131313@cygnus.com>
To: "Chris G. Demetriou" <cgd@sibyte.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
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 <cagney@b1.cygnus.com>
* 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 <cagney@b1.cygnus.com>
* 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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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
> <nsd@redhat.com>
>
> [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 <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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
> <nsd@redhat.com>
>
> [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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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
> <nsd@redhat.com>
>
> [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 <ac131313@cygnus.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Michael Snyder <msnyder@cygnus.com>, 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> <o5ofxptzcp.fsf@toenail.toronto.redhat.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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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 <ac131313@cygnus.com>
To: David Taylor <taylor@cygnus.com>
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 <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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 <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nicholas Duffek <nsd@redhat.com>, 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 <ac131313@cygnus.com>
To: Nicholas Duffek <nsd@redhat.com>
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 <msnyder@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nicholas Duffek <nsd@redhat.com>, 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 <msnyder@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, 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: <o58zogfvwx.fsf@toenail.toronto.redhat.com>
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 <cgd@sibyte.com>
:
: * 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 <jingham@apple.com>
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 <jingham@inghji.apple.com>
* 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 <dberlin@redhat.com>
To: Jim Ingham <jingham@apple.com>
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: <Pine.LNX.4.10.10101121507570.8389-100000@www.cgsoftware.com>
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFA] New register definition interface
[not found] <200101032042.PAA14850@nog.bosbc.com>
2001-01-05 11:56 ` [RFA] New register definition interface Stephane Carrez
@ 2001-01-13 18:22 ` Andrew Cagney
1 sibling, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2001-01-13 18:22 UTC (permalink / raw)
To: Nicholas Duffek; +Cc: gdb-patches
BTW, Is there a working example of this code at work? It is very hard
to comment on interfaces without (partially :-) working examples. The
PowerPC perhaphs?
enjoy,
Andrew
From ac131313@cygnus.com Sat Jan 13 18:38:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Sat, 13 Jan 2001 18:38:00 -0000
Message-id: <3A6110CB.D5E3CE0B@cygnus.com>
References: <3A5FB8E3.8E778C41@cygnus.com> <200101131951.f0DJpHo04858@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00113.html
Content-length: 1124
Nick Duffek wrote:
>
> On 13-Jan-2001, Andrew Cagney wrote:
>
> >I'm confused. Your saying that the CLI changes depend on regs.c?
>
> Yes.
I think this is wrong then. It should be possible to just tweek an
existing target and have it make use of of your new info-registers code.
A quick glance suggests that the code is relying on register attribue
information not currently available through the existing register
interface. All that hopefully needs to be done is for that interface to
be formally specified (added to gdbarch?).
You may even find a willing volunteer to do the work.
> >It should be possible to code the cli so that it doesn't specificly
> >depend on regs.c.
>
> It is possible. I'll look into changing that, but for now, can it be
> committed without that modification? This is an internal implementation
> issue that won't affect clients of either module, and I'd really like to
> make the interface available.
Unfortunatly the problem isn't an internal implementation issue. Rather
it is that the CLI is making assumptions about unpublished (as in not in
gdbarch) reg interfaces.
Andrew
From ac131313@cygnus.com Sat Jan 13 18:53:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Sat, 13 Jan 2001 18:53:00 -0000
Message-id: <3A611431.C70732@cygnus.com>
References: <3A5F0871.E77E5294@cygnus.com> <200101131858.f0DIw4004850@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00114.html
Content-length: 431
BTW,
In reading the coding standard I would interpret ``try to avoid'' as
``don't do this in new code''. For instance where the standard
indicates:
Try to avoid assignments inside if-conditions. For example, don't write
this:
if ((foo = (char *) malloc (sizeof *foo)) == 0)
fatal ("virtual memory exhausted");
I'd interpret it as don't do this in new code. Even though there are
many examples in existing code.
Andrew
From nsd@redhat.com Sat Jan 13 23:54:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Sat, 13 Jan 2001 23:54:00 -0000
Message-id: <200101140801.f0E81if04993@rtl.cygnus.com>
References: <3A60F18C.335A7444@cygnus.com>
X-SW-Source: 2001-01/msg00115.html
Content-length: 364
On 14-Jan-2001, Andrew Cagney wrote:
>FYI
>Just an asside, some coding comments (this code is likely to have a very
>long life time and be looked over by many eyes so best to get it right
>straight up).
Sorry Andrew, I didn't realize your email wasn't CCed gdb-patches when I
CCed my response there. (I am intending to CC _this_ response there,
though.)
Nick
From nsd@redhat.com Sat Jan 13 23:56:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Sat, 13 Jan 2001 23:56:00 -0000
Message-id: <200101140803.f0E83re04998@rtl.cygnus.com>
References: <3A610CD4.FD75BCF4@cygnus.com>
X-SW-Source: 2001-01/msg00116.html
Content-length: 291
On 14-Jan-2001, Andrew Cagney wrote:
>BTW, Is there a working example of this code at work?
Yes, but not that I can publish at the moment.
>The PowerPC perhaphs?
I've been considering that. The various PPC chips have varied register
sets that this interface should handle nicely.
Nick
From mrg@cygnus.com Sun Jan 14 03:59:00 2001
From: matthew green <mrg@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: Re: patch for compiles that don't define "unix"
Date: Sun, 14 Jan 2001 03:59:00 -0000
Message-id: <22097.979473536@cygnus.com>
X-SW-Source: 2001-01/msg00117.html
Content-length: 145
hi folks.
could someone please approve & apply the patch from
http://sources.redhat.com/ml/gdb-patches/2000-12/msg00156.html
thanks,
.mrg.
From fnasser@redhat.com Sun Jan 14 08:11:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: matthew green <mrg@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: patch for compiles that don't define "unix"
Date: Sun, 14 Jan 2001 08:11:00 -0000
Message-id: <3A61CF62.34A9FFE2@redhat.com>
References: <22097.979473536@cygnus.com>
X-SW-Source: 2001-01/msg00118.html
Content-length: 960
Hi Matthew,
Sorry for the delay.
This is not the proper fix though. The rdi-share subdirectory is
supposed to
contain code shared with ARM, so we shouldn't make local modifications
in there
(unless absolutely necessary).
In this case we are better off with a more general fix that will solve
all possible
occurrences of the lack of "unix" problem.
You should define this symbol through some configuration test that
results in
a -Dunix being generated. This way you do not change the files in a
"share"
directory and fix this all around and even catch something that people
add in
the future.
Regards,
Fernando
matthew green wrote:
>
> hi folks.
>
> could someone please approve & apply the patch from
>
> http://sources.redhat.com/ml/gdb-patches/2000-12/msg00156.html
>
> thanks,
>
> .mrg.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From ac131313@cygnus.com Sun Jan 14 16:15:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Sun, 14 Jan 2001 16:15:00 -0000
Message-id: <3A62408E.A745B2D6@cygnus.com>
References: <3A610CD4.FD75BCF4@cygnus.com> <200101140803.f0E83re04998@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00119.html
Content-length: 2252
Nick Duffek wrote:
>
> On 14-Jan-2001, Andrew Cagney wrote:
>
> >BTW, Is there a working example of this code at work?
>
> Yes, but not that I can publish at the moment.
>
> >The PowerPC perhaphs?
>
> I've been considering that. The various PPC chips have varied register
> sets that this interface should handle nicely.
It is much easier to justify the acceptance of your changes if there is
a real live working example. Especially one that demonstrates how easy
(?) it is to update an existing target.
At present there is no reason to hurry with the change.
Could I strongly encourage you to do this in two separate steps:
o sort out the cli/cli* stuff so that
it is independant of regs.c
demonstrate this
o then sort out regs.c
I know this is more onerous on your part, however, I can see significant
long term benefits in sorting out cliregs so that it is independant of
regs.c. To put it another way, if that work isn't done, then I suspect
that, apart from the new obscure ports comming out of Red Hat, your work
will just sit on a shelf gathering dust :-(. I'll try to explain why
I'm somewhat negative.
Both MI and Insight (GDBtk) have been screaming out for a mechanism that
added formatting information to the register description. I think your
cliregs code provides a proof-of-concept of this.
Unfortunatly, cliregs assumes your custom regs.c when obtaining that
information. That in turn means that for an existing target to provide
those annotations it must completly re-implement its register interface
(and as they say in the clasics, if it ain't broke, don't fix it :-( ).
Simiarly, for MI and Insight, this new annotation information might look
useful, however, since it is only provided by a few new and obscure
targets that use a custom regs.c there is no real incentive to exploit
it.
If instead, published interfaces (based around GDBARCH and REGNUM) were
created and cliregs used those then I'd expect both MI and Insight to
also quickly adopt them - they wouldn't be reliant on a custom regs.c.
Similarly, since only an incremental change to the target - add the new
methods - would be needed, it would be very easily to tweek existing
targets so that they too could benefit from this code.
Andrew
From fnasser@redhat.com Mon Jan 15 07:37:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: [infrun.c] Fix to "nexti".
Date: Mon, 15 Jan 2001 07:37:00 -0000
Message-id: <3A6318BF.A9A43A10@redhat.com>
References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com>
X-SW-Source: 2001-01/msg00120.html
Content-length: 2628
If there is a maintainer for this code please speak up.
Otherwise I will check this in under the "obvious fix" rule.
This thing is broken, is annoying lots of people and this patch
has been submitted (and reposted again) a long time ago.
Fernando
Fernando Nasser wrote:
>
> 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
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From cgf@redhat.com Mon Jan 15 08:36:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: [infrun.c] Fix to "nexti".
Date: Mon, 15 Jan 2001 08:36:00 -0000
Message-id: <20010115113635.B26739@redhat.com>
References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com> <3A6318BF.A9A43A10@redhat.com>
X-SW-Source: 2001-01/msg00121.html
Content-length: 287
On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote:
>If there is a maintainer for this code please speak up.
>
>Otherwise I will check this in under the "obvious fix" rule.
Do we really have an "obvious fix" rule? It seems that there is
some confusion on this issue.
cgf
From kevinb@cygnus.com Mon Jan 15 09:50:00 2001
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: [infrun.c] Fix to "nexti".
Date: Mon, 15 Jan 2001 09:50:00 -0000
Message-id: <1010115175046.ZM6315@ocotillo.lan>
References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com> <3A6318BF.A9A43A10@redhat.com> <20010115113635.B26739@redhat.com> <cgf@redhat.com>
X-SW-Source: 2001-01/msg00122.html
Content-length: 462
On Jan 15, 11:36am, Christopher Faylor wrote:
> On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote:
> >If there is a maintainer for this code please speak up.
> >
> >Otherwise I will check this in under the "obvious fix" rule.
>
> Do we really have an "obvious fix" rule? It seems that there is
> some confusion on this issue.
We do not have an "obvious fix" rule. See
http://sources.redhat.com/ml/gdb-patches/2000-04/msg00468.html
Kevin
From mrg@cygnus.com Mon Jan 15 10:29:00 2001
From: matthew green <mrg@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: re: patch for compilers that don't define "unix"
Date: Mon, 15 Jan 2001 10:29:00 -0000
Message-id: <8062.979583347@cygnus.com>
References: <3A61CF62.34A9FFE2@redhat.com>
X-SW-Source: 2001-01/msg00123.html
Content-length: 1402
This is not the proper fix though. The rdi-share subdirectory is supposed to
contain code shared with ARM, so we shouldn't make local modifications in there
(unless absolutely necessary).
how about this then? tested on netbsd/i386 and solaris 2.6. you'll need to
regenerate `configure' after applying this patch.
thanks.
2001-01-15 matthew green <mrg@redhat.com>
* configure.in: Define missing `__unix' if `__unix__' is present.
* configure: Regenerate.
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.53
diff -p -r1.53 configure.in
*** configure.in 2000/12/21 16:16:17 1.53
--- configure.in 2001/01/15 18:21:54
*************** if test x${want_included_regex} = xtrue;
*** 703,708 ****
--- 703,718 ----
AC_DEFINE(USE_INCLUDED_REGEX)
fi
AC_SUBST(REGEX)
+
+ # NetBSD compiler defines __unix__ only; rdi-share needs __unix.
+ AC_CACHE_CHECK([for NetBSD [__unix__]], gdb_cv_missing_netbsd___unix,
+ [AC_EGREP_CPP(lose, [
+ #if defined (__unix__) || !defined (__unix)
+ lose
+ #endif],[gdb_cv_missing_netbsd___unix=yes],[gdb_cv_missing_netbsd___unix=no])])
+ if test x$gdb_cv_missing_netbsd___unix = xyes; then
+ CFLAGS="$CFLAGS -D__unix"
+ fi
# In the Cygwin environment, we need some additional flags.
AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
From fnasser@redhat.com Mon Jan 15 10:31:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: [infrun.c] Fix to "nexti".
Date: Mon, 15 Jan 2001 10:31:00 -0000
Message-id: <3A63418D.513E833@redhat.com>
References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com> <3A6318BF.A9A43A10@redhat.com> <20010115113635.B26739@redhat.com> <1010115175046.ZM6315@ocotillo.lan>
X-SW-Source: 2001-01/msg00124.html
Content-length: 1725
Kevin Buettner wrote:
>
> On Jan 15, 11:36am, Christopher Faylor wrote:
>
> > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote:
> > >If there is a maintainer for this code please speak up.
> > >
> > >Otherwise I will check this in under the "obvious fix" rule.
> >
> > Do we really have an "obvious fix" rule? It seems that there is
> > some confusion on this issue.
>
> We do not have an "obvious fix" rule. See
>
> http://sources.redhat.com/ml/gdb-patches/2000-04/msg00468.html
>
If you go throughout the list you'll find that it has been mentioned and
invoked several times in other messages. It is not well defined though,
and it does not seem to be written anywhere either.
As it is not written what to do when the maintainers do not respond and
something is broken. Do we keep downloading rotten code? These bugs
are very costly in that people waste hours of work because of them.
The message above mentions a problem with regards to small fixes in
codes outside one's maintainership that go wrong. Sometimes
the original problem is fixed but some other is created.
That is why we use CVS. The change can be reversed and the maintainer
(when he/she shows up) has a complete record of what has been changed
and
why (in addition to the list archives).
I don't know what is the better/right solution to the problem, but we do
have a problem now with regarding to bug fixes, specially small fix to
harmful ones. We do need a fast track to them and even consider
temporary
fixes (properly marked with FIXME and entries in the TODO file).
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From fnasser@redhat.com Mon Jan 15 10:35:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: matthew green <mrg@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: patch for compilers that don't define "unix"
Date: Mon, 15 Jan 2001 10:35:00 -0000
Message-id: <3A63429D.B915C05A@redhat.com>
References: <8062.979583347@cygnus.com>
X-SW-Source: 2001-01/msg00125.html
Content-length: 1792
matthew green wrote:
>
>
> This is not the proper fix though. The rdi-share subdirectory is supposed to
> contain code shared with ARM, so we shouldn't make local modifications in there
> (unless absolutely necessary).
>
> how about this then? tested on netbsd/i386 and solaris 2.6. you'll need to
> regenerate `configure' after applying this patch.
>
Thank you Matthew.
I will give it a spin and commit it in a couple of days if nobody
disagrees.
Regards,
Fernando
> thanks.
>
> 2001-01-15 matthew green <mrg@redhat.com>
>
> * configure.in: Define missing `__unix' if `__unix__' is present.
> * configure: Regenerate.
>
> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.53
> diff -p -r1.53 configure.in
> *** configure.in 2000/12/21 16:16:17 1.53
> --- configure.in 2001/01/15 18:21:54
> *************** if test x${want_included_regex} = xtrue;
> *** 703,708 ****
> --- 703,718 ----
> AC_DEFINE(USE_INCLUDED_REGEX)
> fi
> AC_SUBST(REGEX)
> +
> + # NetBSD compiler defines __unix__ only; rdi-share needs __unix.
> + AC_CACHE_CHECK([for NetBSD [__unix__]], gdb_cv_missing_netbsd___unix,
> + [AC_EGREP_CPP(lose, [
> + #if defined (__unix__) || !defined (__unix)
> + lose
> + #endif],[gdb_cv_missing_netbsd___unix=yes],[gdb_cv_missing_netbsd___unix=no])])
> + if test x$gdb_cv_missing_netbsd___unix = xyes; then
> + CFLAGS="$CFLAGS -D__unix"
> + fi
>
> # In the Cygwin environment, we need some additional flags.
> AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From msnyder@redhat.com Mon Jan 15 10:46:00 2001
From: Michael Snyder <msnyder@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [Fwd: RFA: [infrun.c] Fix to "nexti".]
Date: Mon, 15 Jan 2001 10:46:00 -0000
Message-id: <3A634581.9C1C76CD@redhat.com>
X-SW-Source: 2001-01/msg00126.html
Content-length: 747
Christopher Faylor wrote:
>
> On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote:
> >If there is a maintainer for this code please speak up.
> >
> >Otherwise I will check this in under the "obvious fix" rule.
>
> Do we really have an "obvious fix" rule? It seems that there is
> some confusion on this issue.
We do (I think), but when you're discussing infrun.c, I'm not
sure that any change can be regarded as "obviously correct".
At least not in the wait_for_inferior/handle_event area.
By eyeball, this change looks correct to me, or at least
"not obviously incorrect". I would like to see it tested,
and perhaps the best way to do that is to apply it and then
notice if there's a sudden uptick in testsuite failures.
Michael
From nsd@redhat.com Mon Jan 15 10:52:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Mon, 15 Jan 2001 10:52:00 -0000
Message-id: <200101151859.f0FIxqG05555@rtl.cygnus.com>
References: <3A62408E.A745B2D6@cygnus.com>
X-SW-Source: 2001-01/msg00127.html
Content-length: 3123
On 15-Jan-2001, Andrew Cagney wrote:
>It is much easier to justify the acceptance of your changes if there is
>a real live working example. Especially one that demonstrates how easy
>(?) it is to update an existing target.
I agree, but it's not something I'll be able to do immediately.
> o sort out the cli/cli* stuff so that
> it is independant of regs.c
You've convinced me. I've done most of that work, but due to constraints
in my schedule at the moment, it might be a few weeks before I can post
the tested patch.
There's one technical problem: when an architecture selects one of several
competing module implementations, the other implementations shouldn't
initialize themselves for that architecture.
For example, regcache.c does this in _initialize_regcache():
register_gdbarch_swap (NULL, 0, build_regcache);
build_regcache() attaches a chunk of malloc()ed memory to each
architecture. That memory is wasted in architectures that use regs.c
instead of regcache.c.
The same issue applies to cli-regs.c: cliregs_init() attaches memory to
each architecture even if the architecture hasn't set cliregs_info() as
its do_registers_info callback.
Some possible solutions:
1. Each competing module implementation introduces a gdbarch variable
USE_<module-implementation> that architectures must set to 1 if
they're using that implementation. For example:
set_gdbarch_do_registers_info (gdbarch, cliregs_info);
set_gdbarch_use_cliregs (gdbarch, 1);
cliregs_init() would check USE_CLIREGS before allocating memory.
This doesn't work well for regcache.c: each existing architecture
would need to add "set_gdbarch_use_regcache (gdbarch, 1)" to its
initialization routine, or else each future architecture using regs.c
would need to call "set_gdbarch_use_regcache (gdbarch, 0)".
2. Each module introduces a gdbarch variable MODULE_<module-name> that
architectures must set to an implementation-unique value. For
example:
set_gdbarch_do_registers_info (gdbarch, cliregs_info);
set_gdbarch_module_registers_info (gdbarch, MODULE_CLIREGS);
This requires a new header file containing all the MODULE_*
definitions.
3. Introduce a gdbarch interface to query function pointers. Competing
module implementations can use these to check whether they're being
used by the current architecture. For example:
if (GET_DO_REGISTERS_INFO () != cliregs_info)
return;
/* allocate memory */
To avoid the footprint of a GET_*() function for every gdbarch.sh
entry, a per-entry flag could be added that controls whether that
function is needed.
I'm partial to option 3, and I volunteer to implement it if you give
pre-approval to the approach.
Speaking of gdbarch.sh changes, what do you think about the idea of
translating gdbarch.sh into C and automatically generating gdbarch.[ch] as
transient compile-time entities? Running gdbarch.sh takes about 25
seconds on my 650MHz Pentium, and I often forget to run it after applying
or reverting patches that change it.
Nick
From jingham@apple.com Mon Jan 15 11:39:00 2001
From: Jim Ingham <jingham@apple.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Mon, 15 Jan 2001 11:39:00 -0000
Message-id: <B6889200.268C%jingham@apple.com>
References: <Pine.LNX.4.31.0101122216180.15353-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00128.html
Content-length: 6895
Daniel,
>> I understand that there is some argument over whether the current
>> implementation of C++ symbol lookup is the right one, but while it is in
>> place, simple fixes to it need to get into the sources quickly.
>
> I'd happily check them in under an obvious bugfix rule, but I don't want
> to step on any toes.
> I had enough fun doing that trying to figure out what exact areas of code
> C++ maintainer covers, and I still couldn't tell you.
> If someone with definite maintainership over the symbol tables says I can
> check in the fixes, i'll do it. Otherwise, i won't.
> Sorry.
I sympathize, but in this case the fix really is trivial... This one really
does fall under the obvious bugfix rule if any fix does...
>
>
>> It is
>> not sufficient to say that the crash was reported in this forum -
>> Fernando didn't make the connection either, and he is no slouch to say
>> the least...
>
> Err, i'm curious, if you noticed a problem with crashes trying to print
> C++ objects, why didn't you ask me or Jim, as i'm C++ maintainer, and he's
> symbol table maintainer.
Because we have a fairly hacked version of gdb, including a lot of patches
for Objective C, and I always suspect them first when I see any symbol
related problem. By the time I was sure this was not the problem, I also
had found the bug & fixed it. I don't want to send you guys chasing a
phantom problem that only appears in our sources. (And yes, once MacOS X
makes its way out the door, we will turn out attention to submitting these
patches back into the main sources, but until then we are more of a service
organization for all the other folks at Apple that are madly trying to
finish up MacOS X...)
>
>> And most gdb users don't read gdb patches. Sure,
> i'll give you that.
>
>>
>> Just like no user error, no matter how stupid, should ever result in a
>> crash, no patch that keeps gdb from crashing should be refused unless
>> the maintainer can come up with another solution quickly. It is one
>> thing if gdb doesn't find a symbol, or reports some data wrong. That is
>> bad, but there is leisure to argue over method, since users can
>> generally work around it and still get their job done. If gdb crashes -
>> particularly on a common code path, then users are just stuck...
> If they use CVS versions, yes.
I am not sure what you mean by this. We have a fairly hacked version of
GDB, but we work pretty hard to keep re-synching with the CVS sources, so
that when we finally get time to submit patches, we won't have a massive
update to do first... However, if you mean we should work from CVS +
unapproved patches submitted to the patches mailing list, that is going to
make things very much worse for us. Then we would have our changes, plus
the official sources, plus some random collection of other patches we aren't
responsible for. Yuck! And if you mean stick with 5.0, that would mean we
get pretty out of synch, and then have a big merge job to do every half-year
to year.
>
>>
>> If it is really the case that this patch is waiting on Jim's approval,
>> do we need to have a "fast track crash prevention approval mechanism" in
>> the Maintainer system for gdb?
> We do, it's the obvious bugfix rule, but it's hard to say what is
> obvious to everyone.
> I don't feel comfortable making that call right now, I'm pretty tired of
> taking the backlash from the people who think it isn't obvious/needed
> approval which invariably happens.
>
> As I said, isn't the only patch i've got outstanding, and most of them are
> trivial
> fixes/improvements, because I've not yet submitted some large improvements
> made to memory usage/demangling speed/symbol lookup speed for C++/every
> language except C/infrastructure improvements for C++/dwarf2 improvements.
> Among other improvements. Normally, I would just keep pinging Jim until I
> get a response, but to be honest, all the politicking and crap that
> has happened with regards to the steering committee, etc, has
> kinda demotivated me, and it's hard to motivate myself to contribute to
> gdb outside of work, either large or small improvements.
> I'm sure it'll pass in a month or so.
Okay, I only heard about all the steering committee by looking over Stan &
Klee's shoulders, but it did seem pretty counter-productive. No slagging on
JimB, either, but it doesn't help that a maintainer of a the relevant
portion of GDB doesn't actually work on it right now :-(
>>
>> This sort of thing makes gdb look really bad.
> Yeah, but it's only in gdb CVS, don't forget.
> I get the feeling you guys are shipping CVS gdb's to people.
> Well, it's not just a feeling, I have a powerbook with OS X 4F8 (acquired
> through a lot of pain and trouble) on it, and
> I just looked, and it's GDB 20000912, a CVS version.
As I said above, we have a bunch of changes in our sources, but we try to
keep it synched with gdb from CVS every so often. There aren't official
releases often enough for them to be a good base. And this bug has been
around long enough without fixes that if there were more frequent releases
it would still be in one, so I don't see this as viable solution... So what
are you suggesting we do?
>
> Which explains why you keep mentioning users, when the bug only exists in
> CVS.
> This is a very bad idea to be doing.
I really don't understand this. What else are we supposed to be basing our
sources on? There are two options here, apply patches from the Patches list
in advance of their acceptance, or just stick with "official" releases (i.e.
5.0)
There are lots of good patches, and lots of bad ones, in the patches mailing
list. It is better, I think, for us to let the "experts" in the Maintainers
group sort them out, and then use the results of this vetting process. That
IS what the whole Maintainer's (or Helpers??) structure is for. Seems like
subverting this process will just cause us more trouble.
On the other hand, does anyone think an unmodified 5.0 is a good release to
base our efforts on? It has been around for a while now, and has its own
share of bugs that HAVE been fixed. In any case, you don't really WANT most
of your gdb users to stick with the 5.0 release, do you? That would mean
that the CVS changes are being tested by some set of Red Hat customers, and
that is about all. That would not be a very good idea.
> However, if you like, I'll happily make sure C++ nicely, if I didn't have
> to go through a ton of pain to get new builds so I could check it out (IE
> I was seeded the same as the other developers who got 4F8 and friends the
> normal way)
> I know it's in Darwin CVS, but I can't make that compile without the right
> versions of OS X anyway.
>
We should take this part off line, but the Darwin version of gdb SHOULD
build on 4F8. I haven't tried it in a while, but I can't think of anything
we have done that would break this.
Jim
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-01-13 18:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200101032042.PAA14850@nog.bosbc.com>
2001-01-05 11:56 ` [RFA] New register definition interface Stephane Carrez
2001-01-13 18:22 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox