Estou trabalhando no Contiki 2.7 com o destino mbxxx. Ao criar meu código, o vinculador reclamou de umasobreposição das seções .ARM.exidx e .data. Depois de alguns ajustes no script do vinculador contiki-2.7 / cpu / stm32w108 / gnu-stm32w108.ld, corrigi o problema substituindo:

__exidx_start = .;
__exidx_end = .;

com:

.ARM.exidx : {
    __exidx_start = .;
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    __exidx_end = .;
} >ROM_region

Mais tarde, quando tentei ver a lista de cabeçalhos de alguns outros aplicativos de exemplo usando objdump -h, não encontrei essa seção .ARM.exidx específica, enquanto ela está presente no meu aplicativo. Pesquisando sobre .ARM.exidx me levou ao fato de que ele é usado para algum tratamento de exceção em c ++. Como meu código é um código C puro, por que esta seção está presente no meu código? Quando geralmente o .ARM.exidx está presente em um código e qual é a sua utilidade?

==================================================== ================================

Bem, não, eu não tenho essas opções de compilador. Na verdade, estou usando a API do AxTLS e rasgou o código de manipulação de certificados e o portou para o contiki. Em algumas escavações adicionais, encontrei um comportamento suspeito na implementação bigint. Para ser breve ... eis o corpo de uma função do arquivo bigint.c:

static bigint *bi_int_multiply(BI_CTX *ctx, bigint *bia, comp b)
{
   int j = 0, n = bia->size;
   bigint *biR = alloc(ctx, n + 1);
   comp carry = 5;
   comp *r = biR->comps;
   comp *a = bia->comps;

   check(bia);

   /* clear things to start with */
   memset(r, 0, ((n+1)*COMP_BYTE_SIZE));


   do
   {
       long_comp tmp = *r + (long_comp)a[j]*b + carry;
   //    *r++ = (comp)tmp;              /* downsize */
       carry = (comp)(tmp >> COMP_BIT_SIZE);
   } while (++j < n);

  // *r = carry;
  bi_free(ctx, bia);

  return trim(biR);
}

se as partes comentadas (a atribuição da variável r) não forem comentadas, a coisa .ARM.exidx aparecerá, caso contrário, não aparecerá! Agora isso pode ser explicado ???

==================================================== ================================

Não encontrei nada fora do comum usado na implementação dealloc(). Houve 2 referências dealloca() usado em alguma região separada do código, que substitui pormalloc() efree(), mas isso também não resolveu o problema.alloc() implementação tem apenas chamadas paramalloc(),realloc() efree()