gdb patches on FreeBSD 4.9 stable

[Peter Dufault]

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:

http://www.opengroup.org/onlinepubs/007908799/xsh/sysshm.h.html

the relevant text is:

"The pid_t, time_t, key_t and size_t types are defined as described in 
<sys/types.h>...
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

Peter Dufault
HD Associates, Inc.


 
Return-Path: <gregmatu at poczta.onet.pl>
Mailing-List: contact rtems-users-help at rtems.com; run by ezmlm
Delivered-To: mailing list rtems-users at rtems.com
Received: (qmail 10436 invoked from network); 12 Mar 2004 19:48:01 -0000
Received: from unknown (HELO smtp4.poczta.onet.pl) (213.180.130.28)
  by 0 with SMTP; 12 Mar 2004 19:48:01 -0000
Received: from vpdn.adm.onet.pl ([213.180.131.58]:46326 "EHLO
	waw01195115.visp.energis.pl") by ps4.test.onet.pl 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 poczta.onet.pl>
X-Mailer: The Bat! (v1.41) UNREG / CD5BF9353B3B7091
Reply-To: Gregory Matus <gregmatu at poczta.onet.pl>
X-Priority: 3 (Normal)
Message-ID: <0865.040312 at poczta.onet.pl>
To:	rtems-users <rtems-users at rtems.com>,
	sashti srinivasan <svasn_rtems at yahoo.com>
Subject: Re: Timer resolution et al : Implementation of Read_timer()
In-reply-To: <20040311082052.95949.qmail at web61009.mail.yahoo.com>
References: <20040311082052.95949.qmail at web61009.mail.yahoo.com>
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
    disable_interrupts;
      latch_timer0;
      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;
    enable_interrupts;

    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


-- 
Gregory