gdb patches on FreeBSD 4.9 stable

Peter Dufault dufault at
Fri Mar 12 17:24:51 UTC 2004

On Mar 12, 2004, at 12:13 PM, Ralf Corsepius wrote:

> Pardon, but I must be missing something, RTEMS doesn't have sys/ipc.h
> nor sys/shm.h.
> If I understand you correctly, you seem to describe a problem when
> building gdb for *-rtems targts on FreeBSD. In this case, you should 
> try
> to discuss this issue with the gdb maintainers.
> Ralf

'Tag Ralf.  I'm talking about the GDB patches that I downloaded from 
the RTEMS web site that are applied to gdb-5.3/sim/ppc.

Those patches add the files hw_shm.c and hw_sem.c (I believe, as the 
".orig" files are zero-size).

As why FreeBSD is wrong and why sys/ipc.h is redundant - I looked up 
"shm.h" and single unix specification on google.  The link is:

the relevant text is:

"The pid_t, time_t, key_t and size_t types are defined as described in 
In addition, all of the symbols from <sys/ipc.h> will be defined when 
this header is included."

Thus I decided that by rights only <sys/shm.h> need be included to use 
the shared memory stuff, but since the RTEMS modifications to gdb 
already include <sys/ipc.h>, it might as well include <sys/types.h> and 
make everybody happy.


Peter Dufault
HD Associates, Inc.

Return-Path: <gregmatu at>
Mailing-List: contact rtems-users-help at; run by ezmlm
Delivered-To: mailing list rtems-users at
Received: (qmail 10436 invoked from network); 12 Mar 2004 19:48:01 -0000
Received: from unknown (HELO (
  by 0 with SMTP; 12 Mar 2004 19:48:01 -0000
Received: from ([]:46326 "EHLO") by with ESMTP
	id <S898827AbUCLTop>; Fri, 12 Mar 2004 20:44:45 +0100
Date:	Fri, 12 Mar 2004 20:46:53 +0100
From:	Gregory Matus <gregmatu at>
X-Mailer: The Bat! (v1.41) UNREG / CD5BF9353B3B7091
Reply-To: Gregory Matus <gregmatu at>
X-Priority: 3 (Normal)
Message-ID: <0865.040312 at>
To:	rtems-users <rtems-users at>,
	sashti srinivasan <svasn_rtems at>
Subject: Re: Timer resolution et al : Implementation of Read_timer()
In-reply-To: <20040311082052.95949.qmail at>
References: <20040311082052.95949.qmail at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

Thursday, March 11, 2004, sashti wrote:

>      8254 offers facility to read the current value of
> counter at any time.  In the clock driver, the global
> variable,
>    rtems_unsigned32 Clock_driver_ticks
>   is used for counting each clock tick.  This and the
> current snapshot of counter0 can together be used to
> measure with 1 microsecond accuracy.  Will it be
> correct to do so?

I think that it is possible (and even simple) to implement new_read_timer
function as part of clock driver. I imagine it as follows:

  struct tt { uint ticks;
              uint usecs };
  microseconds_per_isr should be static and global in ckinit.c;

  new_read_timer (struct tt *arg) is
      temp_timer0_ticks = read and store (latched) msb,lsb values from
                   timer0's counter (like in read_timer), it ;
      temp_clock_ticks = Clock_driver_ticks;
      clock_isr_passed = Clock_isrs_per_tick - Clock_isrs;

    arg->ticks = temp_clock_ticks;
    arg->usecs = clock_isr_passed * mikroseconds_per_isr
                 + TICK_TO_MICROSECOND(temp_timer0_ticks);
   end new_read_timer;

There is no need for timer_init but new_read_timer should be
called instead of the former. The difference between the first and
last call gives us passed time. User should take care when the value
from second call is less then from first it means that
clock_driver_ticks wraped around (typicaly after 2^32*10msec = 497days)

What do you think about the idea? Is it right or do I missed anything?

> With Regards
> Srinivasan


More information about the users mailing list