date:20210513

Inconsistent behaviour with respect to the ticks in the *_when() directives

2021-05-13 Thread Sebastian Huber


Hello,

I noticed that we have an inconsistent behaviour with respect to the 
handling of the ticks member in the *_when() directives. In all *_when() 
directives the ticks member is not used to calculate the watchdog 
expiration time, see also:


https://lists.rtems.org/pipermail/users/2020-December/068006.html

However, the rtems_task_wake_when() directive ignores the ticks member 
of the time of day completely, unlike the rtems_timer_fire_when() and 
rtems_timer_server_fire_when() directives which check that the ticks are 
valid and then ignore them.


We should use a common way to deal with the ticks member. If we ignore 
the value, then this would make it more difficult to support it in the 
future. The watchdog implementation supports a nanoseconds resolution. 
If we check the ticks in rtems_task_wake_when() existing applications 
may get an error status after the change.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v7] rtems-debugger: Fixed 32bit pointers

2021-05-13 Thread Stephen Clark

Using 32bit types like uint32_t for pointers creates issues on 64 bit
architectures like AArch64. Replaced occurrences of these with
uintptr_t, which will work for both 32 and 64 bit architectures. Added
hex_decode_uintptr function to rtems-debugger.
---
 cpukit/libdebugger/rtems-debugger-server.c | 32 ++
 cpukit/libdebugger/rtems-debugger-target.c |  2 +-
 cpukit/libdebugger/rtems-debugger-target.h |  2 +-
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-server.c 
b/cpukit/libdebugger/rtems-debugger-server.c
index 975ec23a30..c82ced2aa9 100644
--- a/cpukit/libdebugger/rtems-debugger-server.c
+++ b/cpukit/libdebugger/rtems-debugger-server.c
@@ -154,6 +154,26 @@ hex_encode(int val)
   return "0123456789abcdef"[val & 0xf];
 }
 
+static inline uintptr_t
+hex_decode_uintptr(const uint8_t* data)
+{
+  uintptr_t ui = 0;
+  size_t  i;
+  if (data[0] == '-') {
+if (data[1] == '1')
+  ui = (uintptr_t) -1;
+  }
+  else {
+for (i = 0; i < (sizeof(ui) * 2); ++i) {
+  int v = hex_decode(data[i]);
+  if (v < 0)
+break;
+  ui = (ui << 4) | v;
+}
+  }
+  return ui;
+}
+
 static inline DB_UINT
 hex_decode_uint(const uint8_t* data)
 {
@@ -1438,10 +1458,10 @@ remote_read_memory(uint8_t* buffer, int size)
   if (comma == NULL)
 remote_packet_out_str(r_E01);
   else {
-DB_UINT addr;
+uintptr_t addr;
 DB_UINT length;
 int r;
-addr = hex_decode_uint(&buffer[1]);
+addr = hex_decode_uintptr(&buffer[1]);
 length = hex_decode_uint((const uint8_t*) comma + 1);
 remote_packet_out_reset();
 r = rtems_debugger_target_start_memory_access();
@@ -1468,10 +1488,10 @@ remote_write_memory(uint8_t* buffer, int size)
   comma = strchr((const char*) buffer, ',');
   colon = strchr((const char*) buffer, ':');
   if (comma != NULL && colon != NULL) {
-DB_UINT addr;
+uintptr_t addr;
 DB_UINT length;
 int r;
-addr = hex_decode_uint(&buffer[1]);
+addr = hex_decode_uintptr(&buffer[1]);
 length = hex_decode_uint((const uint8_t*) comma + 1);
 r = rtems_debugger_target_start_memory_access();
 if (r == 0) {
@@ -1519,9 +1539,9 @@ remote_breakpoints(bool insert, uint8_t* buffer, int size)
 comma2 = strchr(comma1 + 1, ',');
 if (comma2 != NULL) {
   uint32_t capabilities;
-  DB_UINT  addr;
+  uintptr_t  addr;
   DB_UINT  kind;
-  addr = hex_decode_uint((const uint8_t*) comma1 + 1);
+  addr = hex_decode_uintptr((const uint8_t*) comma1 + 1);
   kind = hex_decode_uint((const uint8_t*)comma2 + 1);
   capabilities = rtems_debugger_target_capabilities();
   switch (buffer[1]) {
diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
b/cpukit/libdebugger/rtems-debugger-target.c
index bf7579700d..34e4e84d2f 100644
--- a/cpukit/libdebugger/rtems-debugger-target.c
+++ b/cpukit/libdebugger/rtems-debugger-target.c
@@ -168,7 +168,7 @@ rtems_debugger_target_reg_table_size(void)
 }
 
 int
-rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT kind)
+rtems_debugger_target_swbreak_control(bool insert, uintptr_t addr, DB_UINT 
kind)
 {
   rtems_debugger_target* target = rtems_debugger->target;
   rtems_debugger_target_swbreak* swbreaks;
diff --git a/cpukit/libdebugger/rtems-debugger-target.h 
b/cpukit/libdebugger/rtems-debugger-target.h
index f2abbe5fd3..db356e1f07 100644
--- a/cpukit/libdebugger/rtems-debugger-target.h
+++ b/cpukit/libdebugger/rtems-debugger-target.h
@@ -200,7 +200,7 @@ extern void 
rtems_debugger_target_exception_print(CPU_Exception_frame* frame);
  * Software breakpoints. These are also referred to as memory breakpoints.
  */
 extern int rtems_debugger_target_swbreak_control(boolinsert,
- DB_UINT addr,
+ uintptr_t addr,
  DB_UINT kind);
 
 /**
-- 
2.27.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: code review: help implementing clock_montonic

2021-05-13 Thread Gedare Bloom

On Wed, May 12, 2021 at 2:42 PM zack_on_the_speed_chanel
 wrote:
>
> > This ticket mostly references the need for a test. Have you tried to
> > write a test for the missing functionality?
> >
> How I made a test for it was to create the timer using timer_create() . It 
> also said to use a previous test with timer_realtime and i tested it with  
> sometime similar to PSXtimer02 test. I  got a invalid argument error when I 
> tried it. Joel told me i also have to impliment the monotonic clock
>
>
> >his math doesn't make sense to me. explain what you're trying to do?
>
> I wanted calculate the remaining time with the timespec. I assumed that the 
> timespec contained the total time seconds+miliseconds. I knew that a cpu tick 
> is an uint32. So i converted to timspec
>
>   remaining = (uint32_t) ( ptimer->Timer.expire - now );
>
> to something like
> expire->tv.nsec+expire->tv.sec  - spec->tv.nsec+spec->tv.sec);
>

This doesn't work. Example:
now = 0s 9ns
expire = 1s 0ns

expire - now = 1ns
expire.nsec + expire.sec - now.nsec + now.sec = -9 cast to
uint32_t is 3294967297ns or so.

Use helper functions in rtems/timespec.h or score/timespec.h
(depending where you implement your code, in this case, you probably
use the score services).

>
> > > Yes, settime is an important function to distinguish between MONOTONIC
> > and REALTIME cases. That is going to be tricky to think through.
>
> Where do you want to check the clock type. I though I only need to 
> distinguish between both when getting the value of the clock. I don't exactly 
> know what needs to be done me being really new to posix and operating system 
> development.
>
The monotonic clock cannot be set.

>
>
> Zack
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, May 11, 2021 6:23 AM, Gedare Bloom  wrote:
>
> > On Fri, May 7, 2021 at 12:53 PM zack_on_the_speed_chanel
> > zack_on_the_speed_cha...@protonmail.ch wrote:
> >
> > > hello,
> > > Currenttly i'm trying to implement the clock_monotonic which was part of 
> > > ticket #3889. So far these are the changes are as follows
> >
> > This ticket mostly references the need for a test. Have you tried to
> > write a test for the missing functionality?
> >
> > > ptimer->clock_type= &clock_id;
> > > in the timer create i added a field for the timer id and saved it when 
> > > the timer was made. Then in getttime I used the appropriate timers to get 
> > > the time.
> > > for example.
> > > if (ptimer->clock_type ==CLOCK_REALTIME) {
> > > Per_CPU_Control *cpu;
> > > struct timespec spec;
> > > struct timespec expire;
> > >
> > > cpu = _POSIX_Timer_Acquire_critical( ptimer, &lock_context );
> > >
> >
> > Maybe move the clock_type check to here?
> >
> > > _TOD_Get(spec);
> > >   _Timespec_From_ticks( expire, &ptimer->Timer.expire);
> > >
> > >
> > > if (spec->tv.nsec+spec->tv.sec > expire->tv.nsec+expire->tv.sec ) {
> > >
> > >   remaining = (uint32_t) (expire->tv.nsec+expire->tv.sec  - 
> > > spec->tv.nsec+spec->tv.sec);
> > >
> >
> > this math doesn't make sense to me. explain what you're trying to do?
> >
> > > } else {
> > >   remaining = 0;
> > > }
> > >
> > > _Timespec_From_ticks( remaining, &value->it_value );
> > > value->it_interval = ptimer->timer_data.it_interval;
> > >
> > > _POSIX_Timer_Release( cpu, &lock_context );
> > > return 0;
> > >
> > >
> > > }
> > > Here i made two separate cases for getting the time. Also joel told me to 
> > > I feel that it is a bit redundant to call everything using timespec to 
> > > calculating remaining time and then just use timespec_From_ticks to get 
> > > the time. It was a recommendation from Joel. Did I make the correct 
> > > change. Also I assume that Delete does not need any changes because It 
> > > does not require any measuring of time. Is there anything i need to 
> > > change for timer_settime?
> >
> > Yes, settime is an important function to distinguish between MONOTONIC
> > and REALTIME cases. That is going to be tricky to think through.
> >
> > > Thanks
> > > Zack
> > >
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v6] rtems-debugger: Fixed 32bit pointers

2021-05-13 Thread Gedare Bloom

On Wed, May 12, 2021 at 1:21 PM Stephen Clark  wrote:
>
> Using 32bit types like uint32_t for pointers creates issues on 64 bit
> architectures like AArch64. Replaced occurrences of these with uintptr_t,
> which will work for both 32 and 64 bit architectures. Added hex_decode_uintptr
> function to rtems-debugger.
> ---
>  cpukit/include/rtems/shellconfig.h |  8 ++
>  cpukit/libdebugger/rtems-debugger-server.c | 32 ++
>  cpukit/libdebugger/rtems-debugger-target.c |  2 +-
>  cpukit/libdebugger/rtems-debugger-target.h |  2 +-
>  4 files changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/cpukit/include/rtems/shellconfig.h 
> b/cpukit/include/rtems/shellconfig.h
> index c5fcf4a45e..07860fbbc3 100644
> --- a/cpukit/include/rtems/shellconfig.h
> +++ b/cpukit/include/rtems/shellconfig.h
> @@ -98,6 +98,7 @@ extern rtems_shell_cmd_t rtems_shell_RTRACE_Command;
>extern rtems_shell_cmd_t rtems_shell_ROUTE_Command;
>extern rtems_shell_cmd_t rtems_shell_NETSTATS_Command;
>extern rtems_shell_cmd_t rtems_shell_PING_Command;
> +  extern rtems_shell_cmd_t rtems_shell_TTCP_Command;
>  #endif
>
>  /*
> @@ -516,6 +517,13 @@ extern rtems_shell_alias_t * const 
> rtems_shell_Initial_aliases[];
>defined(CONFIGURE_SHELL_COMMAND_PING)
>  &rtems_shell_PING_Command,
>#endif
> +
> +  #if (defined(CONFIGURE_SHELL_COMMANDS_ALL_NETWORKING) && \
> +   !defined(CONFIGURE_SHELL_NO_COMMAND_TTCP)) || \
> +  defined(CONFIGURE_SHELL_COMMAND_TTCP)
> +&rtems_shell_TTCP_Command,
> +  #endif
> +
What's this stuff?

>  #endif
>
>  /* Miscanellous shell commands */
> diff --git a/cpukit/libdebugger/rtems-debugger-server.c 
> b/cpukit/libdebugger/rtems-debugger-server.c
> index 975ec23a30..c82ced2aa9 100644
> --- a/cpukit/libdebugger/rtems-debugger-server.c
> +++ b/cpukit/libdebugger/rtems-debugger-server.c
> @@ -154,6 +154,26 @@ hex_encode(int val)
>return "0123456789abcdef"[val & 0xf];
>  }
>
> +static inline uintptr_t
> +hex_decode_uintptr(const uint8_t* data)

nit: I'd prefer you call it hex_decode_addr().

> +{
> +  uintptr_t ui = 0;
> +  size_t  i;
> +  if (data[0] == '-') {
> +if (data[1] == '1')
> +  ui = (uintptr_t) -1;
> +  }
> +  else {
> +for (i = 0; i < (sizeof(ui) * 2); ++i) {
> +  int v = hex_decode(data[i]);
> +  if (v < 0)
> +break;
> +  ui = (ui << 4) | v;
> +}
> +  }
> +  return ui;
> +}
> +
>  static inline DB_UINT
>  hex_decode_uint(const uint8_t* data)
>  {
> @@ -1438,10 +1458,10 @@ remote_read_memory(uint8_t* buffer, int size)
>if (comma == NULL)
>  remote_packet_out_str(r_E01);
>else {
> -DB_UINT addr;
> +uintptr_t addr;
>  DB_UINT length;
>  int r;
> -addr = hex_decode_uint(&buffer[1]);
> +addr = hex_decode_uintptr(&buffer[1]);
>  length = hex_decode_uint((const uint8_t*) comma + 1);
>  remote_packet_out_reset();
>  r = rtems_debugger_target_start_memory_access();
> @@ -1468,10 +1488,10 @@ remote_write_memory(uint8_t* buffer, int size)
>comma = strchr((const char*) buffer, ',');
>colon = strchr((const char*) buffer, ':');
>if (comma != NULL && colon != NULL) {
> -DB_UINT addr;
> +uintptr_t addr;
>  DB_UINT length;
>  int r;
> -addr = hex_decode_uint(&buffer[1]);
> +addr = hex_decode_uintptr(&buffer[1]);
>  length = hex_decode_uint((const uint8_t*) comma + 1);
>  r = rtems_debugger_target_start_memory_access();
>  if (r == 0) {
> @@ -1519,9 +1539,9 @@ remote_breakpoints(bool insert, uint8_t* buffer, int 
> size)
>  comma2 = strchr(comma1 + 1, ',');
>  if (comma2 != NULL) {
>uint32_t capabilities;
> -  DB_UINT  addr;
> +  uintptr_t  addr;
>DB_UINT  kind;
> -  addr = hex_decode_uint((const uint8_t*) comma1 + 1);
> +  addr = hex_decode_uintptr((const uint8_t*) comma1 + 1);
>kind = hex_decode_uint((const uint8_t*)comma2 + 1);
>capabilities = rtems_debugger_target_capabilities();
>switch (buffer[1]) {
> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
> b/cpukit/libdebugger/rtems-debugger-target.c
> index bf7579700d..34e4e84d2f 100644
> --- a/cpukit/libdebugger/rtems-debugger-target.c
> +++ b/cpukit/libdebugger/rtems-debugger-target.c
> @@ -168,7 +168,7 @@ rtems_debugger_target_reg_table_size(void)
>  }
>
>  int
> -rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT 
> kind)
> +rtems_debugger_target_swbreak_control(bool insert, uintptr_t addr, DB_UINT 
> kind)
>  {
>rtems_debugger_target* target = rtems_debugger->target;
>rtems_debugger_target_swbreak* swbreaks;
> diff --git a/cpukit/libdebugger/rtems-debugger-target.h 
> b/cpukit/libdebugger/rtems-debugger-target.h
> index f2abbe5fd3..db356e1f07 100644
> --- a/cpukit/libdebugger/rtems-debugger-target.h
> +++ b/cpukit/libdebugger/rtems-debugger-target.h
> @@ -200,7 +200,7 @@ extern void 
> rtems_debugger_target_excep

Re: GSoC - Code Formatting and Style Checking for RTEMS score

2021-05-13 Thread Gedare Bloom

On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
>
> Hello everyone,
> Still waiting for some feedback :)
>
> Cheers,
> Ida.
>
> On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
>>
>> Hello everyone,
>> Went through some previous emails and it turns out Sebastian already came up 
>> with a configuration for clang format which works well for RTEMS except for 
>> the fact that some configurations haven't been implemented into clang-format 
>> yet. Using
>>
>> AlignConsecutiveDeclarations: false
>> PointerAlignment: Right
>>
>> Doesn't seem to work.
>> For example in the cpukit/score/src/threadq.c file, something like
>>
>> RTEMS_STATIC_ASSERT(
>> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> == offsetof( struct _Thread_queue_Queue, _name ),
>> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> );
>>
>> RTEMS_STATIC_ASSERT(
>> sizeof( Thread_queue_Syslock_queue )
>> == sizeof( struct _Thread_queue_Queue ),
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> );
>>
>> #if defined(RTEMS_SMP)
>> void _Thread_queue_Do_acquire_critical(
>> Thread_queue_Control *the_thread_queue,
>> ISR_lock_Context *lock_context
>> )
>> {
>> _Thread_queue_Queue_acquire_critical(
>> &the_thread_queue->Queue,
>> &the_thread_queue->Lock_stats,
>> lock_context
>> );
>>
>> becomes this after using the given configuration
>>
>> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> sizeof(struct _Thread_queue_Queue),
>> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>>
>> #if defined(RTEMS_SMP)
>> void _Thread_queue_Do_acquire_critical(Thread_queue_Control 
>> *the_thread_queue,
>> ISR_lock_Context *lock_context) {
>> _Thread_queue_Queue_acquire_critical(
>> &the_thread_queue->Queue, &the_thread_queue->Lock_stats, lock_context);
>>
>> Everything seems manageable except for this alignment issue...
>> This also throws more light on the changes using clang-format 
>> (https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
>>
I think we're willing to concede the pointer alignment. However, it
would be worth spending some time to see if
https://reviews.llvm.org/D27651 can be made to work. The current state
of the code would need to be compared to the patch on that review
board.

Beyond that, documenting the clang-format options to use is next, and
then identifying a plan how to invoke clang-format during a git
workflow is needed.

>> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:
>>>
>>>
>>>
>>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer  
>>> wrote:

 Hello Ida and Gedare,

 On 06/05/2021 06:26, Gedare Bloom wrote:
 > hi Ida,
 >
 > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
 >>
 >> Hello everyone,
 >>
 >> Regarding this project (https://devel.rtems.org/ticket/3860) I went 
 >> with clang-format as we all agreed. I have tested it on some "score" 
 >> files and it made some changes which I don't think are very much in 
 >> line with the RTEMS coding style. However, it wasn't really clear if we 
 >> will chage the RTEMS coding style or try to make changes to 
 >> clang-format to fit the style.
 >> Please will love to know the best option.
 >>
 > We will likely need to consider our choices carefully. If we can find
 > a suitably close style that is already well-supported by clang, and
 > get consensus from the maintainers on a change, then that might be the
 > best route forward.

 +1

 > I think the first thing to do is take the examples
 > that have been shown by Sebastian that are "close" but not quite
 > perfect, and identify the cases where they differ with RTEMS style in
 > order to present for discussion here. If consensus can't be reached to
 > change the style, then we would need to have a plan for how to improve
 > the existing tools for what we have.

 I also found the following tool quite useful to play with the clang
 style config:

 https://zed0.co.uk/clang-format-configurator/

 Maybe it can help a bit to find out what certain options mean.

 >
 > However, I think there is interest in doing less work on the tool
 > side, and more work on how to integrate it into our workflows better.

 +1
>>>
>>>
>>> I agree with all of this from the student perspective. But we will have
>>> to come to some agreement on a machine producible format to
>>> be able to use the integration. A report on what doesn't match would
>>> give us something to chew on while Ida works the integration.
>>>
>>> --joel


 >
 >> Cheers,
 >> Ida.
 >> ___
 >> devel mailing list
 >> devel@rtems.org
 >> http://lists.rtems.org/mailman/listinfo/devel
 > ___
 > devel mailing list
 > devel@rtems.org
 > http://lists.rtems.org/mailman/listinfo/devel
 >
 ___
 devel mailing list
 devel@rtems.org
>

Inconsistent behaviour with respect to the ticks in the *_when() directives

[PATCH v7] rtems-debugger: Fixed 32bit pointers

Re: code review: help implementing clock_montonic

Re: [PATCH v6] rtems-debugger: Fixed 32bit pointers

Re: GSoC - Code Formatting and Style Checking for RTEMS score

5 matches

Site Navigation

Mail list logo

Footer information