Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Scott Bambrough <scottb@netwinder.org>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Fri, 28 Jul 2000 12:26:00 -0000	[thread overview]
Message-ID: <3981DCFE.9D99AB4F@netwinder.org> (raw)
In-Reply-To: <3981D53F.BE84EDCF@cygnus.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 16675 bytes --]

Fernando Nasser wrote:
> 
> > 2000-07-26  Scott Bambrough <scottb@netwinder.org>
> >         * gdb.base/environ.exp: Run tests for all targets.
> >
> > 2000-07-26  Scott Bambrough <scottb@netwinder.org>
> >
> >         * linux-thread.c (linux_threads_pid_to_str):  Change "Pid" to
> >         "process" to allow gdb.base/environ.exp to pass all tests.
> >         Change capitalization on "Thread" for consistency.
> >
> I forwarded the above change to the maintainers requesting their approval.

These two need to go hand in hand, otherwise we get failures in environ.exp.  I
sent a response to Michael Snyder's comments about this to him yesterday.  I
just realized it didn't go to the list; so I forwarded it to the list as well. 
I will wait to check these in until I hear about the change in linux-thread.c. 
I'm also been thinking that maybe I shouldn't enable this for all targets, the
show/set/unset environment commands may fail on embedded targets.  They should
work fine on any target that has an environment.  The info program tests should
work on all targets.  Maybe this test should be split up?  Comments?

> >         * gdb.base/sect-cmd.exp: Run tests for all targets.  Use
> >         'section .text' clause for Linux in set section command
> >         test.
> >         * gdb.base/so-indr-cl.exp: Run tests for *-*-linux-gnu*.

I'll withdraw these, fix them up and resubmit them for approval.

> > 2000-07-26  Scott Bambrough <scottb@netwinder.org>
> >
> >         * gdb.base/recurse.exp: Run tests for all targets.
> >         * gdb.base/so-impl-ld.exp: Added wildcard to
> >         handle the gnu-oldld case on ARM.
> >         * gdb.base/watchpoint.exp (test_stepping): Clear xfail
> >         for ARM targets.

I will apply these today.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From ezannoni@cygnus.com Fri Jul 28 12:26:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Multiarch DO_REGISTERS_INFO
Date: Fri, 28 Jul 2000 12:26:00 -0000
Message-id: <14721.56903.448617.375558@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00349.html
Content-length: 5215

OK to commit?

2000-07-28  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

        * gdbarch.sh: Multiarch DO_REGISTERS_INFO macro.
        * gdbarch.h, gdbarch.c: Regenerate.

Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.32
diff -c -u -p -r1.32 gdbarch.sh
cvs server: conflicting specifications of output style
--- gdbarch.sh  2000/07/27 04:01:24     1.32
+++ gdbarch.sh  2000/07/28 19:24:14
@@ -314,6 +314,7 @@ v:2:MAX_REGISTER_RAW_SIZE:int:max_regist
 f:2:REGISTER_VIRTUAL_SIZE:int:register_virtual_size:int reg_nr:reg_nr::0:0
 v:2:MAX_REGISTER_VIRTUAL_SIZE:int:max_register_virtual_size::::0:-1
 f:2:REGISTER_VIRTUAL_TYPE:struct type *:register_virtual_type:int reg_nr:reg_nr::0:0
+f:2:DO_REGISTERS_INFO:void:do_registers_info:int reg_nr, int fpregs:reg_nr, fpregs::0:0
 #
 v:1:USE_GENERIC_DUMMY_FRAMES:int:use_generic_dummy_frames::::0:-1
 v:2:CALL_DUMMY_LOCATION:int:call_dummy_location::::0:0

Index: gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.26
diff -c -u -r1.26 gdbarch.h
cvs server: conflicting specifications of output style
--- gdbarch.h   2000/07/27 04:01:24     1.26
+++ gdbarch.h   2000/07/28 19:24:42
@@ -389,6 +389,15 @@
 #endif
 #endif
 
+typedef void (gdbarch_do_registers_info_ftype) (int reg_nr, int fpregs);
+extern void gdbarch_do_registers_info (struct gdbarch *gdbarch, int reg_nr, int fpregs);
+extern void set_gdbarch_do_registers_info (struct gdbarch *gdbarch, gdbarch_do_registers_info_ftype *do_registers_info);
+#if GDB_MULTI_ARCH
+#if (GDB_MULTI_ARCH > 1) || !defined (DO_REGISTERS_INFO)
+#define DO_REGISTERS_INFO(reg_nr, fpregs) (gdbarch_do_registers_info (current_gdbarch, reg_nr, fpregs))
+#endif
+#endif
+
 extern int gdbarch_use_generic_dummy_frames (struct gdbarch *gdbarch);
 extern void set_gdbarch_use_generic_dummy_frames (struct gdbarch *gdbarch, int use_generic_dummy_frames);
 #if GDB_MULTI_ARCH

Index: gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.32
diff -c -u -r1.32 gdbarch.c
cvs server: conflicting specifications of output style
--- gdbarch.c   2000/07/27 04:01:24     1.32
+++ gdbarch.c   2000/07/28 19:25:02
@@ -161,6 +161,7 @@
   gdbarch_register_virtual_size_ftype *register_virtual_size;
   int max_register_virtual_size;
   gdbarch_register_virtual_type_ftype *register_virtual_type;
+  gdbarch_do_registers_info_ftype *do_registers_info;
   int use_generic_dummy_frames;
   int call_dummy_location;
   gdbarch_call_dummy_address_ftype *call_dummy_address;
@@ -296,6 +297,7 @@
   0,
   0,
   0,
+  0,
   generic_get_saved_register,
   0,
   0,
@@ -523,6 +525,9 @@
   if ((GDB_MULTI_ARCH >= 2)
       && (gdbarch->register_virtual_type == 0))
     internal_error ("gdbarch: verify_gdbarch: register_virtual_type invalid");
+  if ((GDB_MULTI_ARCH >= 2)
+      && (gdbarch->do_registers_info == 0))
+    internal_error ("gdbarch: verify_gdbarch: do_registers_info invalid");
   if ((GDB_MULTI_ARCH >= 1)
       && (gdbarch->use_generic_dummy_frames == -1))
     internal_error ("gdbarch: verify_gdbarch: use_generic_dummy_frames invalid");
@@ -869,6 +874,13 @@
                       "REGISTER_VIRTUAL_TYPE(reg_nr)",
                       XSTRING (REGISTER_VIRTUAL_TYPE (reg_nr)));
 #endif
+#if defined (DO_REGISTERS_INFO) && GDB_MULTI_ARCH
+  /* Macro might contain `[{}]' when not multi-arch */
+  fprintf_unfiltered (file,
+                      "gdbarch_dump: %s # %s\n",
+                      "DO_REGISTERS_INFO(reg_nr, fpregs)",
+                      XSTRING (DO_REGISTERS_INFO (reg_nr, fpregs)));
+#endif
 #ifdef USE_GENERIC_DUMMY_FRAMES
   fprintf_unfiltered (file,
                       "gdbarch_dump: USE_GENERIC_DUMMY_FRAMES # %s\n",
@@ -1466,6 +1478,13 @@
                         (long) current_gdbarch->register_virtual_type
                         /*REGISTER_VIRTUAL_TYPE ()*/);
 #endif
+#ifdef DO_REGISTERS_INFO
+  if (GDB_MULTI_ARCH)
+    fprintf_unfiltered (file,
+                        "gdbarch_dump: DO_REGISTERS_INFO = 0x%08lx\n",
+                        (long) current_gdbarch->do_registers_info
+                        /*DO_REGISTERS_INFO ()*/);
+#endif
 #ifdef USE_GENERIC_DUMMY_FRAMES
   fprintf_unfiltered (file,
                       "gdbarch_dump: USE_GENERIC_DUMMY_FRAMES = %ld\n",
@@ -2481,6 +2500,23 @@
                                    gdbarch_register_virtual_type_ftype register_virtual_type)
 {
   gdbarch->register_virtual_type = register_virtual_type;
+}
+
+void
+gdbarch_do_registers_info (struct gdbarch *gdbarch, int reg_nr, int fpregs)
+{
+  if (gdbarch->do_registers_info == 0)
+    internal_error ("gdbarch: gdbarch_do_registers_info invalid");
+  if (gdbarch_debug >= 2)
+    fprintf_unfiltered (gdb_stdlog, "gdbarch_do_registers_info called\n");
+  gdbarch->do_registers_info (reg_nr, fpregs);
+}
+
+void
+set_gdbarch_do_registers_info (struct gdbarch *gdbarch,
+                               gdbarch_do_registers_info_ftype do_registers_info)
+{
+  gdbarch->do_registers_info = do_registers_info;
 }
 
 int
From Stephane.Carrez@worldnet.fr Fri Jul 28 12:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@free.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: [Patch 6/7]: 68HC11 port of gdb (sim-misc single step fix)
Date: Fri, 28 Jul 2000 12:46:00 -0000
Message-id: <3982002E.1F34EFF9@worldnet.fr>
References: <39568A82.A0B2BFEB@free.fr> <3980227F.A6FC263B@cygnus.com>
X-SW-Source: 2000-07/msg00353.html
Content-length: 4102

Hi!

Andrew Cagney a écrit :
>
> Stephane Carrez wrote:
> 
> > 2000-06-25  Stephane Carrez  <Stephane.Carrez@worldnet.fr>
> >
> >         * nrun.c (main): Print the simulator statistics only in
> >         verbose mode.
> >         * hw-properties.h (hw_find_integer_array_property): Fix
> >         prototype (use signed_cell).
> 
> I've committed these, thanks.
> 
> >         * sim-resume.c (sim_resume): Install the single step event
> >         after having processed some current pending events. It may happen
> >         that some ticks are not yet processed after a break/single step
> >         command from GDB. In that case, installing the single step event
> >         before processing pending events will activate the single step
> >         without actually having executed any instruction.
> 
> I don't think this is right.  When the simulator does a restart, a
> second has_stepped event would be scheduled and the first would be lost.
> 

Yes but I have another problem.

For my simulator, the number of ticks is advanced at each instruction by
the number of cycles the instruction takes.  I have instructions that
can take 4 cycles up to 70 cycles.  [I'm doing this to keep the simulator
behavior as close as possible to reality.  The timer and all other devices
are in sync with the cpu.]

After each instruction the number of ticks is incremented with 'sim_events_tickn'
by the number of cycles the instruction took.  Sometimes all the ticks are
taken into account, and sometimes some of them are saved in 'nr_ticks_to_process'.
If this happens we process a pending event.  Such event stops the simulator 
(for example because it was a single step). So, at that point, 
nr_ticks_to_process != 0.

Now, next time I enter in 'sim_resume', we schedule a single step event for
tick 1. In general this is the next one.  We then call 'sim_events_preprocess'.
Here we rememeber that we have some 'nr_ticks_to_process' and
we process them.  Since the single step event is next (because at T+1),
it is processed and we stop the simulator (before having restarted it!!).

The fix I suggest consists in installing the single step event after we
have processed the pending ticks in 'nr_ticks_to_process'.  By doing so,
the pending ticks in 'nr_ticks_to_process' don't break the single step.

>         Andrew
> 
> > diff -Nrup --exclude-from=gdb-exclude.lst /src/gnu/cygnus/gdb/sim/common/sim-resume.c gdb/sim/common/sim-resume.c
> > --- /src/gnu/cygnus/gdb/sim/common/sim-resume.c Mon Jul 12 13:14:09 1999
> > +++ gdb/sim/common/sim-resume.c Mon Feb 21 09:00:23 2000
> > @@ -51,8 +51,6 @@ sim_resume (SIM_DESC sd,
> >        sim_events_deschedule (sd, engine->stepper);
> >        engine->stepper = NULL;
> >      }
> > -  if (step)
> > -    engine->stepper = sim_events_schedule (sd, 1, has_stepped, sd);
> >
> >    sim_module_resume (sd);
> >
> > @@ -69,6 +67,9 @@ sim_resume (SIM_DESC sd,
> >        sim_events_preprocess (sd, last_cpu_nr >= nr_cpus, next_cpu_nr >= nr_cpus);
> >        if (next_cpu_nr >= nr_cpus)
> >         next_cpu_nr = 0;
> > +
> > +      if (step)
> > +       engine->stepper = sim_events_schedule (sd, 1, has_stepped, sd);
> >
> >        /* Only deliver the siggnal ]sic] the first time through - don't
> >           re-deliver any siggnal during a restart. */
> 
> Note the comment about siggnals[sic].
> 
>         Andrew

ssignal does not seem to be ever used.  It seemed to be ignored in most
simulators (and in sim_engine_run).

I don't reach that point anyway when the problem occurs.  I don't return
from 'sim_events_preprocess' because it calls 'sim_engine_halt' that longjumps
to return (due to single step event we just scheduled).

	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 Stephane.Carrez@worldnet.fr Fri Jul 28 12:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [maint] target maintainers
Date: Fri, 28 Jul 2000 12:46:00 -0000
Message-id: <39820022.79D89624@worldnet.fr>
References: <39813390.FD4535EF@cygnus.com>
X-SW-Source: 2000-07/msg00352.html
Content-length: 548

Hi!

Andrew Cagney a écrit :
> [...]
> 
>         m68hc11         maintenance only

I can be the maintainer of that platform.

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 Stephane.Carrez@worldnet.fr Fri Jul 28 12:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@free.fr>, gdb-patches@sourceware.cygnus.com
Subject: Re: [Patch 5/7]: 68HC11 port of gdb (sim-overlap address maps)
Date: Fri, 28 Jul 2000 12:46:00 -0000
Message-id: <3982000B.B590C544@worldnet.fr>
References: <39568A64.830EC800@free.fr> <39802053.B4BCAD4E@cygnus.com>
X-SW-Source: 2000-07/msg00351.html
Content-length: 1573

Hi!

Thanks a lot for integration of the patches!

Andrew Cagney a écrit :
> 
> Stephane Carrez wrote:
> >
> > Hi!
> >
> > The following patch adds the support to overlap some address spaces.
> > I need this for 68hc11 because the IO is mapped over the normal memory.
> > The internal RAM is mapped in the same way. Both may be moved at any
> > 4K boundary. The EEPROM can be unmapped, showing up what is underneath it.
> >
> > Each device has an overlap flag that tells whether overlapping is
> > allowed or not. The default is to disable that. This is the current
> > behavior.
> >
> > When overlapping is allowed, we just record the mapping rather than
> > rejecting it.
> 
> I'm not sure I understand the change.  The memory model has the idea of
> layers.  Overlapping memory can normally be handled by that.  The memory
> would be set up as:
> 
>         first layer:    eeprom
>         second layer:   memory
> 
> is this in addition to the layers?
> 
>         Andrew

Ok. I didn't understand the role of the level. It's not easy to guess that...:-)

If what I understand now is right, I should be able to do the overlapping I need.

Thanks,
	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 guo@cup.hp.com Fri Jul 28 13:07:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] gdbarch.c(gdbarch_dump)
Date: Fri, 28 Jul 2000 13:07:00 -0000
Message-id: <Pine.LNX.4.10.10007281305390.8159-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-07/msg00354.html
Content-length: 1243

This patch is to prevent sizeof.exp 'maint print arch' to trigger
gdb_internal_error ().  inferior.h defines default to be the
gdb_internal_error () call.


Fri Jul 28 13:01:35	Jimmy Guo	<guo@cup.hp.com>

	* gdbarch.c (gdbarch_dump): dump CALL_DUMMY_BREAKPOINT_OFFSET value
	only if CALL_DUMMY_BREAKPOINT_OFFSET_P.

Index: gdbarch.c
/usr/local/bin/diff -c -L gdbarch.c gdbarch.c@@/main/_guo_unified_merge/7 gdbarch.c
*** gdbarch.c
--- gdbarch.c	Fri Jul 28 12:51:17 2000
***************
*** 1456,1464 ****
                        (long) CALL_DUMMY_START_OFFSET);
  #endif
  #ifdef CALL_DUMMY_BREAKPOINT_OFFSET
!   fprintf_unfiltered (file,
!                       "gdbarch_dump: CALL_DUMMY_BREAKPOINT_OFFSET = 0x%08lx\n",
!                       (long) CALL_DUMMY_BREAKPOINT_OFFSET);
  #endif
  #ifdef CALL_DUMMY_BREAKPOINT_OFFSET_P
    fprintf_unfiltered (file,
--- 1456,1465 ----
                        (long) CALL_DUMMY_START_OFFSET);
  #endif
  #ifdef CALL_DUMMY_BREAKPOINT_OFFSET
!   if (CALL_DUMMY_BREAKPOINT_OFFSET_P)
!     fprintf_unfiltered (file,
! 			"gdbarch_dump: CALL_DUMMY_BREAKPOINT_OFFSET = 0x%08lx\n",
! 			(long) CALL_DUMMY_BREAKPOINT_OFFSET);
  #endif
  #ifdef CALL_DUMMY_BREAKPOINT_OFFSET_P
    fprintf_unfiltered (file,


  reply	other threads:[~2000-07-28 12:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <39803B5C.9C31BB15@netwinder.org>
     [not found] ` <3980469B.E0BD7ED2@cygnus.com>
2000-07-27  8:11   ` Scott Bambrough
2000-07-27 17:39   ` Andrew Cagney
2000-07-28 11:47 ` Fernando Nasser
2000-07-28 12:26   ` Scott Bambrough [this message]
2000-07-28 13:43     ` Fernando Nasser
2000-08-02 10:59 Donn Terry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3981DCFE.9D99AB4F@netwinder.org \
    --to=scottb@netwinder.org \
    --cc=fnasser@cygnus.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox