Can a module use 'ref' sections on ARM?

Question

I have a module that contains functions with a ref attribute. This places the .text in a different section. The way the ARM stack frame unwinding works is that two additional sections are placed in an ELF file. These sections provide tables to the ARM unwind.c. The module.c file populates these tables when loading a module.

When using the .ref.text section, the two sections .ARM.extab.ref.text and .ARM.exidx.ref.text are created by gcc-4.7 to allow unwinding of this code. Unfortunately, module.c only scans for .init, .devinit, etc and does not add these sections. If we turn on CONFIG_DEBUG_KMEMLEAK, and a __ref frame is active during an allocation, the stack trace code give many unwind: Index not found messages in the kernel logs.

1. Is it wrong to use __ref in a module?
2. Should there by architechure linker files for the ARM that place the .ref extab and exidx in the core .ARM.extab and .ARM.exidx sections?
3. Why am I the only one to see this? I have 2.6.36, but the problem seems to exist in the mainline.

Answer 1

Both the 68k and the ia64 have additional linker files, with the ia64 fitting the ARM __ref requirements.

Adding the following to arch/arm/Makefile,

# Glob 'ref' unwind tables.
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm/module.lds

And arch/arm/modules.lds as,

SECTIONS {
    /DISCARD/ : {
        *(.ARM.exidx.exit.text)
        *(.ARM.extab.exit.text)
        *(.ARM.exidx.devexit.text)
        *(.ARM.extab.devexit.text)
    }
    /* Group unwind sections together: */
    .ARM.extab : { *(.ARM.extab*) }
    .ARM.exidx : { *(.ARM.exidx*) }
    .text : { *(.text); *(.ref.text); *(.rodata*); }
}

will put the __ref annotations unwind information together with normal unwind code.

This may solve multiple unwind: Index not found kernel log messages when using modules on ARM Linux. The /DISCARD/ portion is not needed on with a newer module.c as it supports module .exit unwind info; but it is useful for 2.6.36 where this information is newer used.

This may cause other issues and hasn't been run past the ARM Linux mailing list to be vetted for issues.