[PATCH 18/52] arm/shared/abort/abort.c: Fix warnings and clean up

Joel Sherrill joel.sherrill at oarcorp.com
Wed Oct 8 20:22:31 UTC 2014


On 10/8/2014 3:14 PM, Gedare Bloom wrote:
> On Wed, Oct 8, 2014 at 3:16 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>> ---
>>  c/src/lib/libbsp/arm/shared/abort/abort.c | 44 +++++++++++++++++++------------
>>  1 file changed, 27 insertions(+), 17 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/shared/abort/abort.c b/c/src/lib/libbsp/arm/shared/abort/abort.c
>> index a686a62..05432f8 100644
>> --- a/c/src/lib/libbsp/arm/shared/abort/abort.c
>> +++ b/c/src/lib/libbsp/arm/shared/abort/abort.c
>> @@ -1,6 +1,10 @@
>>  /*
>>   *  ARM CPU Dependent Source
>>   *
>> + *  If you want a small footprint RTEMS, pls use simple_abort.c
>> + */
>> +
>> +/*
>>   *  COPYRIGHT (c) 2007 Ray Xu.
>>   *  mailto: Rayx at gmail dot com
>>   *
>> @@ -10,8 +14,6 @@
>>   *  Copyright (c) 2002 Advent Networks, Inc
>>   *      Jay Monkman <jmonkman at adventnetworks.com>
>>   *
>> - *  If you want a small footprint RTEMS, pls use simple_abort.c
>> - *
>>   *  The license and distribution terms for this file may be
>>   *  found in the file LICENSE in this distribution or at
>>   *  http://www.rtems.org/license/LICENSE.
>> @@ -44,21 +46,26 @@
>>  #define SET_REG(r, ctx, v)   (((uint32_t   *)ctx)[r] = v)
>>  #define GET_OFFSET(insn)     (insn & 0xfff)
>>
>> -uint32_t       g_data_abort_cnt = 0;
>> +/*
>> + * Prototypes
>> + */
>> +void _print_full_context(uint32_t);
>> +void do_data_abort(uint32_t, uint32_t, Context_Control *);
>> +
>> +uint32_t g_data_abort_cnt = 0;
>>  /*this is a big overhead for MCU only got 16K RAM*/
>> -uint32_t       g_data_abort_insn_list[1024];
>> +uint32_t g_data_abort_insn_list[1024];
>>
>>
>>  char *_print_full_context_mode2txt[0x20]={
>> -   [0x0]="user",  /* User */
>> -       [0x1]="fiq",   /* FIQ - Fast Interrupt Request */
>> -       [0x2]="irq",   /* IRQ - Interrupt Request */
>> -       [0x3]="super", /* Supervisor */
>> -       [0x7]="abort", /* Abort */
>> -       [0xb]="undef", /* Undefined */
>> -       [0xf]="system" /* System */
>> -    };
>> -
>> +  [0x0]="user",  /* User */
>> +  [0x1]="fiq",   /* FIQ - Fast Interrupt Request */
>> +  [0x2]="irq",   /* IRQ - Interrupt Request */
>> +  [0x3]="super", /* Supervisor */
>> +  [0x7]="abort", /* Abort */
>> +  [0xb]="undef", /* Undefined */
>> +  [0xf]="system" /* System */
>> +};
>>
>>  void _print_full_context(uint32_t spsr)
>>  {
>> @@ -82,7 +89,7 @@ void _print_full_context(uint32_t spsr)
>>                : [arm_switch_reg] "=&r" (arm_switch_reg), [prev_sp] "=&r" (prev_sp), [prev_lr] "=&r" (prev_lr),
>>                 [cpsr] "=&r" (cpsr)
>>                : [spsr] "r" (spsr)
>> -             : "cc");
>> +              : "cc");
>>
>>      printk("Previous sp=0x%08x lr=0x%08x and actual cpsr=%08x\n",
>>             prev_sp, prev_lr, cpsr);
>> @@ -102,8 +109,11 @@ void _print_full_context(uint32_t spsr)
>>   * All unhandled instructions cause the system to hang.
>>   */
>>
>> -void do_data_abort(uint32_t   insn, uint32_t   spsr,
>> -                    Context_Control *ctx)
>> +void do_data_abort(
>> +  uint32_t insn,
>> +  uint32_t spsr,
>> +  Context_Control *ctx
>> +)
>>  {
>>      /* Clarify, which type is correct, CPU_Exception_frame or Context_Control */
>>      uint8_t               decode;
>> @@ -156,6 +166,6 @@ void do_data_abort(uint32_t   insn, uint32_t   spsr,
>>      while(1) {
>>          continue;
>>      }
>> -    return;
>> +    (void) level; /* avoid set but unused warning */
> I'd prefer to see this closer to where level was set.
Is immediately after the rtems_interrupt_disable() ok?
> -Gedare
>>  }
>>
>> --
>> 1.9.3
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985




More information about the devel mailing list