The compiled object files won't do much good; I need to see the code that
convinced the assembler to generate the bad relocations. You can (and
should) go ahead and create the ticket at
http://sourceforge.net/tracker/?group_id=42303&atid=432701 for tracking
purposes, but I probably won't do anything with it until there's a
reproducing test case.
Peter
On Thu, Jun 30, 2011 at 10:04 AM, Sergio Campamá <sergiocamp...@gmail.com>wrote:
> I can't seem to get an example working (and I mean for it to fail).. And
> the
> complete code is in separated in many files, and kinda private, I can't
> post
> it online. What else can I do to track this bug? I remember having the same
> problem in mspgcc4 too, but not in mspgcc3.
>
> Maybe, since its a linking error, I can upload the compiled obj files.
>
> Thanks, and best regards,
>
>
> On Thu, Jun 30, 2011 at 8:49 AM, Albert ARIBAUD <albert.arib...@free.fr
> >wrote:
>
> > Le 30/06/2011 14:35, Sergio Campamá a écrit :
> >
> > In that case, how can I specify that I want the function pointer to be
> in
> >> RAM and not in the flash?
> >>
> >
> > You don't need to, or shouldn't, since the function pointer is a
> non-const
> > initially set to 0, so will go in a r/w data section anyway (probably
> BSS),
> > certainly not in FLASH. IOW, there is no error in this respect in your
> code.
> >
> > Besides, the error messages are not about the function pointer variable;
> > they are about the two functions the addresses of which you want to put
> in
> > the pointer.
> >
> > So IMO the issue lies in the way the compiler computes (or fails to
> > compute) these addresses, rather than the way it locates the function
> > pointer variable -- probably the compiler generates a relocation record
> > based on what it thinks each function's location will be, but once they
> are
> > mapped, the linker cannot perform the requested relocation.
> >
> > Amicalement,
> > --
> > Albert.
> >
>
>
>
> --
> --------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
