stm32 - When is .ARM.exidx is used

Question

I am working on Contiki 2.7 with the mbxxx target. While building my code the linker complained about an overlap of .ARM.exidx and .data sections. After some tinkering around with the linker script contiki-2.7/cpu/stm32w108/gnu-stm32w108.ld I fixed the problem by replacing:

__exidx_start = .;
__exidx_end = .;

with:

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

Later when I tried to see the header listing of some other example applications by using objdump -h I did not find this particular .ARM.exidx section, while it is present in my application. Googling about .ARM.exidx led me to the fact that it is used for some c++ exception handling. Since my code is a pure C code, why is this section present on my code? When is generally .ARM.exidx present in a code and what is its utility?

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

Well no, I don't have any such compiler options. I am actually using the AxTLS api and ripped out the certificate handling code and ported it to contiki. On some further digging I found a fishy behaviour in the bigint implementation. To be brief... here is the body of a function from the bigint.c file:

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);
}

if the commented out portions, (the r variable assignment) is uncommented, the .ARM.exidx thingy appears, otherwise it doesn't! Now can this be explained???

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

I didn't find any thing out of the ordinary used in the implementation of alloc(). There were 2 references of alloca() used in some separate region of the code, which I replaced with malloc() and free(), but that didn't fix the problem either. alloc() implementation has only calls to malloc(),realloc() and free()

Answer 1

.ARM.exidx is the section containing information for unwinding the stack. If your C program has functions that print out a stack backtrace, the functions will likely depend on this section being present.

Maybe look for a -funwind-tables or -fexceptions flag in your compiler options.