On Mon, Dec 17, 2012 at 3:02 AM, Ionut Nicu <ionut.n...@cloudbit.ro> wrote:
> Hi,
>
> On Fri, 2012-12-07 at 12:23 +0200, Alexandru Stefan wrote:
>
> > When trying to compile with debugging symbols activated (-g option), the
> > linker puts out the following error messages:
> >
> > build/board_pdd036/drivers/input/buttons.o:(.debug_loc+0x6b):
> > relocation truncated to fit: R_MSP430_16_BYTE against `no symbol'
> > build/board_pdd036/drivers/input/buttons.o:(.debug_loc+0x75):
> > relocation truncated to fit: R_MSP430_16_BYTE against `no symbol'
> >
>
> I've debugged this problem further and found out the source of the
> problem in the ld source code. There's a validation in
> bfd/elf32-msp430.c in function msp430_final_link_relocate:
>
> switch (howto->type)
> {
>
> ...
> case R_MSP430_16_PCREL_BYTE:
> case R_MSP430_16_BYTE:
> bfd_put_16 (input_bfd, MSP430_MASK_16 (srel), contents);
> if (r == bfd_reloc_ok && !MSP430_16_IN_RANGE (srel))
> r = bfd_reloc_overflow;
> break;
> ...
>
> Our problem is that MSP430_16_IN_RANGE (srel) returns 0 and the ld code
> goes on the error path from here.
>
> In our case, it seems there are some relocations inside some debug
> sections (the link error appears only when compiling with -g) which
> exceed the 16-bit address space. I've added the following printf inside
> the if statement:
>
>
> printf("srel = 0x%X, name = %s, section = %s\n", srel, howto->name,
> input_section->name);
>
> and I get something like this in the output:
>
> srel = 0x15431, name = R_MSP430_16_BYTE, section = .debug_loc
> srel = 0x15431, name = R_MSP430_16_BYTE, section = .debug_loc
> srel = 0x3C9A1, name = R_MSP430_16_BYTE, section = .debug_loc
>
>
> I'm not very familiar with ld, but why is this check performed for debug
> sections? Please correct me if I'm wrong, but as far as I know these
> sections have meaning only for the debugger on the host, they don't get
> into the image flashed on the target.
>
The debugger checks all relocations; it doesn't matter whether they're in a
section that gets downloaded or not, as they may be important when running
gdb with a remote target.
I'm at a loss how you could be getting a 32-bit relocation when (per
previous mail) you're using the LTS-20120406 compiler which only generates
references to 16-bit addresses. Perhaps you have something in your code?
Asm statements that place data in far memory are known to cause this issue
with pre-20-bit compilers.
The bug was fixed for the 4.7-based development series in
https://sourceforge.net/tracker/index.php?func=detail&aid=3530932&group_id=42303&atid=432701
See also the thread beginning at
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg10923.html
Peter
>
> Thanks,
> Ionut.
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
