Ok, so I was able to get rid of the error. It happens (sometimes, not
always) when there's a global (defined outside of a function) pointer (to
anything, I tried it as a function pointer, and a struct pointer) and it is
initialized as 0.
So, this throws the unsupported relocation error
void (*callback)() = 0;
This throws a warning of the type "initialization makes pointer from integer
without cast", but compiles anyway
void (*callback)() = 1;
And this doesn't throw anything and compiles correctly
void (*callback)();
I haven't tried if it runs on the msp430 as it may wreak havoc without an
initial value.
But I want to be able to initialize it, because I want it to have a NULL
value so I can check when it is a valid pointer. I have #define NULL 0
because mspgcc doesn't include it, so, in the first error, where there's a
0, in code it actually is
void (*callback)() = NULL;
Maybe NULL can be defined as something else?
Just as I finished writing this, I tried defining this
static void (*callback)() = 0;
and it also worked. Maybe it is because it was a global variable in the
whole program context? I know this is a bad practice, and I will correct it,
but I still think it may be a bug. Maybe worth noting that there were 3
files containing global pointers (3 global pointers in total in the app).
And my cflags were "-D_MSP430 -Os -c -Wall -D_Z1 -mmcu=msp430f2617" and the
lflags = "-mmcu=msp430f2617"
On Thu, Jun 30, 2011 at 1:20 PM, Sergio Campamá <sergiocamp...@gmail.com>wrote:
> As a matter of fact, I am using a Z1 device. But I have never used their
> compiler. I've only used the mspgcc. But the micro they use is a
> MSP430F2617, and that one IS supported by the "uniarch" mspgcc, so the
> binary it generates should work on that device. I don't care really if it
> supports 20bit addresses. In fact, I actually don't even have their tools
> installed in my computer, so it's impossible for them to get invoked. The
> only tools I call are the uniarch mspgcc ones.
>
> Before I installed mspgcc uniarch, I worked with mspgcc3 (the one before
> mspgcc4), and I could compile everything fine with it, and tested it on real
> Z1s.
>
>
> On Thu, Jun 30, 2011 at 11:26 AM, Peter Bigot <big...@acm.org> wrote:
>
>> Just a wild guess based on the "z1" below: If you're using the Zolertia Z1
>> device, I believe the compiler they use is an mspgcc3 fork with support for
>> 20-bit addresses. If that's getting invoked at any point, you would see
>> relocation errors like this: mainline mspgcc does not support 20-bit
>> addresses. Stick with their compiler for everything.
>>
>> If you're not using the Z1, never mind.
>>
>> Peter
>>
>> On Wed, Jun 29, 2011 at 5:14 PM, Sergio Campamá
>> <sergiocamp...@gmail.com>wrote:
>>
>>> Hello,
>>>
>>> I am building a quite complex c program for the msp430, and when linking,
>>> I
>>> get a "warning: internal error: unsupported relocation error" in some,
>>> not
>>> all, obj files. The weird thing is that it generates an output elf file,
>>> but
>>> when loaded, it does nothing. Has anyone stumbled before with this thing?
>>>
>>> It mainly happens when there's some kind of pointer, like a function
>>> pointer
>>> or a regular pointer.
>>>
>>> As an example, this code
>>>
>>> void (*button_callback_1)() = NULL; //button callback is 0 by default
>>>
>>> void button_process_interrupt(uint8_t button)
>>> {
>>> switch(button)
>>> {
>>> case BUTTON_1:
>>> if (button_callback_1 != NULL) button_callback_1();
>>> break;
>>> }
>>> }
>>>
>>> void button_interrupt(uint8_t button)
>>> {
>>> task_add(&button_process_interrupt, TASK_PRIORITY_LOW, button);
>>> }
>>>
>>> void button_register_callback_1(void (*callback)())
>>> {
>>> button_callback_1 = callback;
>>> }
>>>
>>> generates the following errors:
>>>
>>> obj_z1/button.obj: In function `button_process_interrupt':
>>> button.c:(.text+0x8): warning: internal error: unsupported relocation
>>> error
>>> obj_z1/button.obj: In function `button_register_callback_1':
>>> button.c:(.text+0x48): warning: internal error: unsupported relocation
>>> error
>>>
>>> What could be happening? I didn't want to file a bug report until being
>>> sure
>>> this is a bug.
>>>
>>> Thanks for any help I can get. Best regards,
>>>
>>> --
>>> --------------------------------------
>>> Sergio Campamá
>>> sergiocamp...@gmail.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously
>>> valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Mspgcc-users mailing list
>>> Mspgcc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>>
>>>
>>
>
>
> --
> --------------------------------------
>
> Sergio Campamá
> sergiocamp...@gmail.com
>
>
>
--
--------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
