Function going into .rodata

lpcware · ‎06-15-2016

Content originally posted in LPCWare by drobe011 on Mon Feb 17 15:20:27 MST 2014
Recently I ran into an issue that is likely a non problem; mainly because I
rewrote the code, but the issue still troubles me.

Issue:
Function placed into .rodata section with no compiler optimizations.

LPC811
LPCXpresso 6.14
LPCOpen v2.01
Linux Fedora 20 x64
Using straight C (no C++)

(with no optimizations)
.text size is 3900
.data is 0
.bss is 284

The function consists of a switch statement with 6 cases. It still goes into
.rodata if I comment out everything with the exception of the switch-case
structure.

The function is called via a function pointer with no parameters and returns no value.

If there are only 4 cases, it does not go into .rodata. More than 4 it goes
in. Doesn't matter which ones, just as long as there are more than 4, it goes
in.

I compiled the same code, using LPCOpen v2.01 on IAR and it does not go into
.rodata. (using the same machine, but running XP in VB).

If I compile the project with any optimizations, all is good.

If I add __attribute__((optimize(1))) to the function prototype and compile the
project with no optimization, all is good.

It sounds more like I am violating a GCC coding practice, but I have not seen
it before nor can I find anything too specific about it.

However, I wrote a small test building against CMSIS v2.10 in LPCXpresso 6.14
using LPC1347 as the target; nothing unusual.

Used the same test with LPCOpen v2.01 in LPCXpresso 6.14
using LPC811 as the target; function goes into .rodata.

Any ideas or pointers? Or am I being too OCD about where everything is going?

Thanks,

Dave

lpcware · ‎06-15-2016

Content originally posted in LPCWare by drobe011 on Mon Feb 17 19:58:13 MST 2014
Yes, thank you.

From the *.dis :

000002e0 [A_GLOBAL_CONST]:
 2e0:  000a 0000 01ce 0000 019e 0000 01a6 0000     ................
 2f0:  01ae 0000 01b6 0000 01be 0000 01c6 0000     ................

Table is started at 2e4. Not sure why it blobs it right there. It always puts it butted against the last const declared.

I also assumed that a jump/branch table could/would be created with optimizations on; generally not off.

Thanks for your attention,

Dave

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rocketdawg on Mon Feb 17 16:43:35 MST 2014
you would have to lok at the diss-assembly to make sure,
but perhaps the compiler is generating a jump table because the case elements are contiguous and thus it can compute a jump offset.