2

I'm developing on a custom embedded platform with a custom version of gcc, which is based on gcc-2.8.0 (egcs-2.91.02). Yes, it's old. It's for a CoolRISC C816 core.

I face a strange error sometimes, when during the link of my embedded C project gcc gives me this error :

undefined reference to _spill

Indeed, when looking into the temporary *.s file generated by gcc when compiling the source files in those specific cases, I see this kind of instruction :

MOVE __spill+4,%a

I'm surprised because this _spill error only happens once in a while, on multiple big projects (20k+ LOC) there's no sign of this error, and not any reference to _spill in the *.s files.

I already have a fix consisting of allocating _spill in my startup assembly file, but I'd like to know more about this.

What is '_spill' and why do I need it ? Also, if I have to statically allocate it, how to know which size I should give it ?

Edit: As advised in the comments, I looked at the corresponding C code and the line that seems the source of the pack of instructions containing '_spill' is this one : 

pStruct->psConst->puRegister[CONST_VALUE] = 0x00;

Where pStruct is a pointer on a typedef struct (call it Foo) locally declared like this : Foo *pStruct = &MyStruct, with MyStruct an extern variable of type Foo that is in another file. psConst is a const pointer on another typedef struct (call it Bar). puRegister is a member of Bar declared of type volatile uint8_t * And finally, CONST_VALUE is a constant value from an enumerate.

This might therefore be an issue that happens only when there's a lot of dereference in a row, or something related.

Tim
  • 1,853
  • 2
  • 24
  • 36
  • What's the target platform? When you see the `_spill` reference in the generated assembly code, what kind of C code is it generated from? – Michael Burr Jan 23 '17 at 07:24
  • When you for some reason have to work with a compiler old enough to vote a good idea might be to learn to read that compiler code so that you can see why it generates the code it does. Also, it might help to mention architecture you're working on and what code causes this. – Art Jan 23 '17 at 07:36
  • @MichaelBurr The target platform is a CoolRISC C816 core. For the C code I can't tell, it's in a big function but I have difficulties locating the specific place that generates this code. Also when debugging with the disassembly I can't find any instruction looking like a MOVE _spill+4, while replacing _spill with its address found in the map file. – Tim Jan 23 '17 at 07:48
  • @Art Thanks for replying. Please se my answer to Michael Burr's comment. I also found a way to identify the location of this assembly in my C code, I've added it to my question. – Tim Jan 23 '17 at 08:34
  • I've browsed through the ancient code of the closest version of egcs I had available (2.93) and I can't see any place where it would generate a symbol like that. This looks very likely to be related to the unusual CPU architecture you're working on. I'm pretty sure that this is a question can only be answered by whoever made the version of gcc you're using. Either they know how to deal with this or they provide libraries that implement support for this. Pure speculation is that this is support for saving registers in situations where you might not have a functioning stack. – Art Jan 23 '17 at 09:11
  • @Art Thanks for looking into this code. I thought this was a common gcc functionality because there are a lot of mention to `spilling` related to gcc, but it also makes sense that this one is specific to my toolchain. I'll see with the toolchain provider. Anyway what could be the situations where I don't have a functioning stack ? – Tim Jan 23 '17 at 09:38
  • @TimF The term `spill` in a compiler means "we ran out of registers in the register allocator, we need to store some values in memory". Usually that memory is the stack (for local or compiler-generated temporary variables). I don't know when/why the compiler might think you don't have enough stack, I'm pretty sure it's no standard gcc feature. Interrupt/trap handlers? It's all speculation though. Could be something different. – Art Jan 23 '17 at 09:50
  • @Art Thanks again. I confirm what you said, I just had an eye on the gcc code of my toolchain and there is a file treating with this `__spill` thing. That means it definitely is between my toolchain provider and me and I won't have a better answer here. Feel free to turn your comments into an answer, I'll accept it. – Tim Jan 23 '17 at 10:38

0 Answers0