Thanks,
That's actually exactly what I am doing (porting over some USB driver
code), so unfortunately refactoring to remove this requirement isn't
possible for me. I will look into appending my code into the existing
linker scripts to do what I want.
Cheers,
Tim
On Tue, Dec 13, 2011 at 9:38 AM, Peter Bigot <big...@acm.org> wrote:
> On further thought, you'd be better clone-and-owning the standard
> linker scripts (msp430.x at least, maybe a couple of the other ones,
> but you shouldn't need to touch the mcu-specific ones). Insert a
> section specifically for your variables into the correct region
> (presumably REGION_DATA). The main script assumes that it has full
> knowledge of everything that goes into each region, and sets markers
> to denote the start and end addresses for things like initializing BSS
> and copying initialized data from ROM into RAM. I think there would
> be subtle problems that would arise if you tried to append something:
> either the variables you declare would overlay other ones placed by
> the linker, or the address markers would be wrong.
>
> Not knowing your application I can't suggest removing the requirement
> that variables be placed at specific locations, though it's an avenue
> I would seriously explore if it were my problem. The primary case I
> can think of that justifies what you describe involves overlaying
> structures on data placed in peripheral memory (such as the USB
> buffers), in which case this can be done without modifying linker
> scripts (re-use existing symbols, or define new ones).
>
> Peter
>
> On Tue, Dec 13, 2011 at 9:17 AM, Timothy Logan <timothy.lo...@gmail.com>
> wrote:
> > Thanks for everyone's input.
> >
> > I agree that having a linker script would be a cleaner way of
> implementing
> > this and think I am just going to buckle down and use a linker script so
> I
> > do not end up shooting myself in the foot.
> >
> > I want to make it however so that the "sections" that I define like
> > CrazyCasta said are merely appended to the end of the default linker
> script.
> > Reading into the msp430-ld man page, it has the following to say:
> >
> > "If the linker cannot recognize the format of an object file, it will
> assume
> > that it is a linker script. A script specified in this way augments the
> > main linker script used for the link ..... Specifying a script in this
> way
> > merely augments the main linker script, with the extra commands placed
> after
> > the main script; use the -T option to replace the default linker script
> > entirely, but note the effect of the "INSERT" command."
> >
> > So, making a linker script like this (called linker.x):
> >
> > 1 SECTIONS
> > 2 {
> > 3 .mySection 0x0100:
> > 4 {
> > 5 variable1 = 0x2280;
> > 6 variable2 = 0x0820;
> > 7 variable3 = 0x22C8;
> > 8 variable4 = 0x2288;
> > 9 variable5 = 0x2278;
> > 10 variable6 = 0x2270;
> > 11
> > 12 }
> > 13 }
> >
> > And passing it in to the linking step of my Makefile like:
> >
> > $(CC) -Wall $(LDFLAGS) linker.x $(ALLOBJS) -o $(BUILDDIR)/EXAMPLE.ELF
> >
> > should do the trick, right? I do get the following warning:
> >
> > /usr/lib/gcc/msp430/4.5.3/../../../../msp430/bin/ld: warning: linker.x
> > contains output sections; did you forget -T?
> >
> > .. but maybe this is normal?
> >
> > Sorry if this is going too deep into generic-linker questions.
> >
> > Cheers,
> > Tim
> >
> >
> > On Tue, Dec 13, 2011 at 6:48 AM, Peter Bigot <big...@acm.org> wrote:
> >>
> >> On Tue, Dec 13, 2011 at 6:03 AM, JMGross <msp...@grossibaer.de> wrote:
> >> > ----- Ursprüngliche Nachricht -----
> >> > Von: Peter Bigot
> >> > Gesendet am: 12 Dez 2011 21:39:15
> >> >
> >> > On Mon, Dec 12, 2011 at 2:31 PM, Timothy Logan <
> timothy.lo...@gmail.com>
> >> > wrote:
> >> >>> I am porting some code from IAR which involves me having to place a
> >> >>> few
> >> >>> different structures in very specific addresses in the MSP430
> memory.
> >> >
> >> >> You can use asm statements, as are done with the peripheral register
> >> >> declarations. Something like:
> >> >> volatile unsigned int specialdata __asm__("0x1320");
> >> >> will force the definition of specialdata to be placed at address
> >> >> 0x1320.
> >> >
> >> > That's the obvious way.
> >> > However, it must be used with care.
> >> > The variable locations are put as direct addresses into the
> >> > compiler-generated assembly output.
> >> > The linker won't see them or know of them.
> >>
> >> Which is why the real peripheral register declarations use:
> >>
> >> volatile unsigned int P1OUT __asm__("__P1OUT");
> >>
> >> where __P1OUT is a symbolic constant defined at final link time from
> >> the MCU-specific periph.x file. The same thing can be done in this
> >> case so ensure all modules get the same address. The original request
> >> was for a simple way that didn't muck with linker scripts, but if the
> >> potential for inconsistency is a concern the symbol value can also be
> >> provided on the linker command line; see the msp430-ld man page.
> >>
> >> Peter
> >>
> >> > So if two independent compilaiton units (C files)
> >> > Use their own "superstatic variable" and it happens
> >> > to be placed on the same location, you won't get
> >> > an error or even a warning. And the two code parts
> >> > will mess with each others storage then.
> >> >
> >> > Especially dangerous when using libraries, where
> >> > the particular code is not checked/adjusted for every project.
> >> > (so it could be noticed)
> >> >
> >> > JMGross
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Systems Optimization Self Assessment
> >> > Improve efficiency and utilization of IT resources. Drive out cost and
> >> > improve service delivery. Take 5 minutes to use this Systems
> >> > Optimization
> >> > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> >> > _______________________________________________
> >> > Mspgcc-users mailing list
> >> > Mspgcc-users@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Systems Optimization Self Assessment
> >> Improve efficiency and utilization of IT resources. Drive out cost and
> >> improve service delivery. Take 5 minutes to use this Systems
> Optimization
> >> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> >> _______________________________________________
> >> Mspgcc-users mailing list
> >> Mspgcc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
> >
>
------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
