On 25 April 2017 at 20:04, Johannes Bauer wrote: > Hi there, > > I'm using gcc-6.3.0 with the arm-non-eabi target and cross compile for > ARM Cortex-M4. I've just traced an annoyingly elusive issue which > ultimately turned out to be caused by a .jcr section that originates > from gccs CRT. Note that I'm compiling bare metal Cortex-M, so I'm a > million miles away from anything Javaish. There should not be a > Java-related section consuming RAM on my microcontroller, in my opinion. > > When I turn on section garbage collection, it goes away (never > referenced, obviously) but in this particular instance, I cannot turn on > section GC. When I try to discard the section via my linker script, I > get complaints: > > `.jcr' referenced in section `.text' of > /home/joe/bin/gcc-cm4/lib/gcc/arm-none-eabi/6.3.0/crtbegin.o: defined in > discarded section `.jcr' of > /home/joe/bin/gcc-cm4/lib/gcc/arm-none-eabi/6.3.0/crtbegin.o > collect2: error: ld returned 1 exit status > > I'm not the first to encounter this issue, but it doesn't seem to cause > a problem for most people. E.g., I've found this here: > > https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00654.html > > But it doesn't really apply to fixing this. Why not? > Since I do bake my own gcc flavor, I would also be happy with a solution > that'd involve patching around gcc guts, but I'm just too clueless to > know what to touch there. Doesn't the patch show what to change? #undef JCR_SECTION_NAME in libgcc/crtstuff.c (although it looks like the macro has been renamed to __LIBGCC_JCR_SECTION_NAME__).
