Estoy trabajando en Contiki 2.7 con el objetivo mbxxx. Mientras construía mi código, el enlazador se quejaba de unasuperposición de las secciones .ARM.exidx y .data. Después de algunos retoques con el script del vinculador contiki-2.7 / cpu / stm32w108 / gnu-stm32w108.ld, solucioné el problema reemplazando:

__exidx_start = .;
__exidx_end = .;

con:

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

Más tarde, cuando intenté ver el listado de encabezados de algunas otras aplicaciones de ejemplo utilizando objdump -h, no encontré esta sección en particular .ARM.exidx, mientras estaba en mi aplicación. Buscar en Google sobre .ARM.exidx me llevó al hecho de que se utiliza para el manejo de algunas excepciones de c ++. Dado que mi código es un código C puro, ¿por qué esta sección está presente en mi código? ¿Cuándo está generalmente .ARM.exidx en un código y cuál es su utilidad?

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

Pues no, no tengo tales opciones de compilador. De hecho, estoy usando la API de AxTLS, arranqué el código de manejo del certificado y lo porté a contiki. En algunas excavaciones adicionales encontré un comportamiento sospechoso en la implementación de Bigint. Para ser breve ... aquí está el cuerpo de una función del archivo 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);
}

si las partes comentadas, (la asignación de la variable r) no están comentadas, aparece el texto .ARM.exidx, de lo contrario no lo hace. Ahora se puede explicar esto?

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

No encontré nada fuera de lo común utilizado en la implementación dealloc(). Hubo 2 referencias dealloca() utilizado en alguna región separada del código, que he reemplazado conmalloc() yfree(), pero eso tampoco solucionó el problema.alloc() La implementación solo tiene llamadas amalloc(),realloc() yfree()