Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

More ld script questions..

More ld script questions..

2004-01-22 by James Dabbs

In the file <lpc2106-rom.ld>, from the file <lpc2106_gcc.zip> on the
yahoo site..

in the prog output section, there are these entries:

	*(.rodata)
	*(.rodata*)

I understand that the first means "add the entire contents of the
.rodata input segment into the prog output segment," but what is the
function of that second entry with the asterisk after it?

For reference, I've appended the linker script in its entirety.

Thanks for any guidance.




-----BEGIN LINKER SCRIPT-----

/*
SEARCH_DIR( /home/radsett/install/arm-elf/lib)
SEARCH_DIR( /home/radsett/install/lib/gcc-lib/arm-elf/3.3.2)
*/

MEMORY {
   flash : ORIGIN = 0, LENGTH = 120K
   ram : ORIGIN = 0x40000000, LENGTH = 64K
   }

__stack_end__ = 0x40000000 + 64K - 4;
SECTIONS {
  . = 0;
  startup : { *(.startup)} >flash
  prog : {
         *(.text)
         *(.rodata)
         *(.rodata*)
         *(.glue_7)
         *(.glue_7t)
         } >flash
  __end_of_text__ = .;
  .data : {
         __data_beg__ = .;
         __data_beg_src__ = __end_of_text__;
         *(.data)
         __data_end__ = .;
         } >ram AT>flash
  .bss : {
         __bss_beg__ = .;
         *(.bss)
         } >ram
    /* Align here to ensure that the .bss section occupies space up to
       _end.  Align after .bss to ensure correct alignment even if the
       .bss section disappears because there are no input sections.  */
    . = ALIGN(32 / 8);
   }
   . = ALIGN(32 / 8);
   _end = .;
   _bss_end__ = . ; __bss_end__ = . ; __end__ = . ;
   PROVIDE (end = .);

/*
INPUT( -lc -lgcc)
*/

PROVIDE( undefined_instruction_exception = endless_loop);
PROVIDE( software_interrupt_exception = endless_loop);
PROVIDE( prefetch_abort_exception = endless_loop);
PROVIDE( data_abort_exception = endless_loop);
PROVIDE( reserved_exception = endless_loop);
PROVIDE( interrupt_exception = endless_loop);
PROVIDE( fast_interrupt_exception = endless_loop);

PROVIDE( PINSEL0 = 0xE002C000);
PROVIDE( IODIR = 0xE0028008);
PROVIDE( IOCLR = 0xE002800C);
PROVIDE( IOSET = 0xE0028004);

/* UART 0 */

PROVIDE( U0RBR = 0xE000C000);
PROVIDE( U0THR = 0xE000C000);
PROVIDE( U0IER = 0xE000C004);
PROVIDE( U0IIR = 0xE000C008);
PROVIDE( U0FCR = 0xE000C008);
PROVIDE( U0LCR = 0xE000C00C);
PROVIDE( U0LSR = 0xE000C014);
PROVIDE( U0SCR = 0xE000C01C);
PROVIDE( U0DLL = 0xE000C000);
PROVIDE( U0DLM = 0xE000C004);

/* PLL */

PROVIDE( PLLCON = 0xE01FC080);
PROVIDE( PLLCFG = 0xE01FC084);
PROVIDE( PLLSTAT = 0xE01FC088);
PROVIDE( PLLFEED = 0xE01FC08C);

/* MAM */

PROVIDE( MAMCR = 0xE01FC000);
PROVIDE( MAMTIM = 0xE01FC004);

/* VPB */

PROVIDE( VPBDIV = 0xE01FC100);

/* TIMER 0 */

PROVIDE( T0IR = 0xE0004000);
PROVIDE( T0TCR = 0xE0004004);
PROVIDE( T0TC = 0xE0004008);
PROVIDE( T0PR = 0xE000400C);
PROVIDE( T0PC = 0xE0004010);
PROVIDE( T0MCR = 0xE0004014);
PROVIDE( T0MR0 = 0xE0004018);
PROVIDE( T0MR1 = 0xE000401C);
PROVIDE( T0MR2 = 0xE0004020);
PROVIDE( T0MR3 = 0xE0004024);
PROVIDE( T0CCR = 0xE0004028);
PROVIDE( T0CR0 = 0xE000402C);
PROVIDE( T0CR1 = 0xE0004030);
PROVIDE( T0CR2 = 0xE0004034);
PROVIDE( T0EMR = 0xE000403C);


-----END LINKER SCRIPT-----

Re: [lpc2100] More ld script questions..

2004-01-22 by Robert Adsett

At 07:51 AM 1/22/04 -0500, you wrote:
>In the file <lpc2106-rom.ld>, from the file <lpc2106_gcc.zip> on the
>yahoo site..
>
>in the prog output section, there are these entries:
>
>         *(.rodata)
>         *(.rodata*)

Not all the readonly data ends up in .rodata.  Some of it ends up in other 
sections (the * is just a wildcard match).  This is an area of the compiler 
that is vary sparsely documented, at least I couldn't find much 
information.  Lewin?  anyone else?

>For reference, I've appended the linker script in its entirety.

I've got an updated version of that script at 
http://www.aeolusdevelopment.com/Articles/download.html.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Re: [lpc2100] More ld script questions..

2004-01-22 by Lewin A.R.W. Edwards

>>        *(.rodata)
>>        *(.rodata*)
> 
> 
> Not all the readonly data ends up in .rodata.  Some of it ends up in other 
> sections (the * is just a wildcard match).  This is an area of the compiler 

Don't quote me on this, but I _believe_ C++ code may generate stuff in 
segments named .rodata-something. I vigorously avoid C++ in embedded 
projects, so I don't see it a lot.

Note, the syntax above is _not_ redundant. It places ".rodata" without 
suffix first in the image, followed by any ".rodatasomething" data.

-- 
  -- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20

Re: [lpc2100] More ld script questions..

2004-01-22 by Bogdan Marinescu

I can see a rodata.str1.4 section in one of the
programs compiled with gcc for my Atmel AT91M40800
(ARM7TDMI core) board. It's NOT a c++ project and it
doesn't explictly declare any constans; rodata.str1.4
contains all the strings in the source. I have no idea
why it's called like that, but the conclusion is
clear: .rodata is not the only section that can hold
readonly data, so that syntax is not redundant; on the
contrary, it's a very good thing to use it (unless you
don't want to start wondering where your strings are,
which is what I did the first time I compiled my
program and used only *(.rodata) in my linker command
file).

    Bogdan

--- "Lewin A.R.W. Edwards" <larwe@...> wrote:
> >>        *(.rodata)
> >>        *(.rodata*)
> > 
> > 
> > Not all the readonly data ends up in .rodata. 
> Some of it ends up in other 
> > sections (the * is just a wildcard match).  This
> is an area of the compiler 
> 
> Don't quote me on this, but I _believe_ C++ code may
> generate stuff in 
> segments named .rodata-something. I vigorously avoid
> C++ in embedded 
> projects, so I don't see it a lot.
> 
> Note, the syntax above is _not_ redundant. It places
> ".rodata" without 
> suffix first in the image, followed by any
> ".rodatasomething" data.
> 
> -- 
>   -- Lewin A.R.W. Edwards (http://www.zws.com/)
> Learn how to develop high-end embedded systems on a
> tight budget!
>
http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: [lpc2100] More ld script questions..

2004-01-22 by Lewin A.R.W. Edwards

>     I can see a rodata.str1.4 section in one of the
> programs compiled with gcc for my Atmel AT91M40800
> (ARM7TDMI core) board. It's NOT a c++ project and it

I wonder what the difference is, then. If I build a C project (at least, 
the projects I have around here - several of which are _very_ 
complicated), I only get .rodata.

> which is what I did the first time I compiled my
> program and used only *(.rodata) in my linker command
> file).

Hmm. When I encountered this, the linker warned me that it was omitting 
sections. It did not silently discard them.

-- 
  -- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20

Re: [lpc2100] More ld script questions..

2004-01-22 by Bogdan Marinescu

--- "Lewin A.R.W. Edwards" <larwe@...> wrote:
> I wonder what the difference is, then. If I build a
> C project (at least, 
> the projects I have around here - several of which
> are _very_ 
> complicated), I only get .rodata.
   I searched the net a bit and the only thing I found
is that it could be a matter of gcc versions.
Apparently, gcc versions prior to 3.1.x didn't
generate .rodata.strx.y sections. 
> 
> > which is what I did the first time I compiled my
> > program and used only *(.rodata) in my linker
> command
> > file).
> 
> Hmm. When I encountered this, the linker warned me
> that it was omitting 
> sections. It did not silently discard them.
    I just commented out my *(.rodata*) line from the
linker script of the project that has the file with a
.rodata.str1.4 section and the linker didn't give any
warnings. I'm using ld 2.12.

> 
> -- 
>   -- Lewin A.R.W. Edwards (http://www.zws.com/)
> Learn how to develop high-end embedded systems on a
> tight budget!
>
http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

RE: [lpc2100] More ld script questions..

2004-01-22 by James Dabbs

OK..  * is a wildcard.. I guess I should have figure that one out..

Another question, more conceptual.  This ld uses named sections, using >
to say where it will be loaded, and AT> to say where it is at the moment
of reset.  (I think, anyway).  Let's say I also want to use
__attribute__ to define some functions in RAM, naming this ".ramtext" in
my C code.  My guess is that this looks something like this:

  prog : {
         *(.text)
         *(.rodata)
         *(.rodata*)
         *(.glue_7)
         *(.glue_7t)
         __end_of_prog__ = . ;
         } >flash

  .ramtext : {
         __ramtext_beg__ = . ;
         __ramtext_beg_src__ = __end_of_prog__ ;
         *(.ramtext)
         __ramtext_end__ = .;
         } >ram AT>flash

And then my boot.s would just copy (__ramtext_end__ - __ramtext_beg__)
bytes from __ramtext_beg_src__ to __ramtext_beg__.

Is this right?

Thanks.
Show quoted textHide quoted text
-----Original Message-----
From: James Dabbs [mailto:jdabbs@...] 
Sent: Thursday, January 22, 2004 7:52 AM
To: lpc2100@yahoogroups.com
Subject: [lpc2100] More ld script questions..


In the file <lpc2106-rom.ld>, from the file <lpc2106_gcc.zip> on the
yahoo site..

in the prog output section, there are these entries:

	*(.rodata)
	*(.rodata*)

I understand that the first means "add the entire contents of the
.rodata input segment into the prog output segment," but what is the
function of that second entry with the asterisk after it?

For reference, I've appended the linker script in its entirety.

Thanks for any guidance.




-----BEGIN LINKER SCRIPT-----

/*
SEARCH_DIR( /home/radsett/install/arm-elf/lib)
SEARCH_DIR( /home/radsett/install/lib/gcc-lib/arm-elf/3.3.2)
*/

MEMORY {
   flash : ORIGIN = 0, LENGTH = 120K
   ram : ORIGIN = 0x40000000, LENGTH = 64K
   }

__stack_end__ = 0x40000000 + 64K - 4;
SECTIONS {
  . = 0;
  startup : { *(.startup)} >flash
  prog : {
         *(.text)
         *(.rodata)
         *(.rodata*)
         *(.glue_7)
         *(.glue_7t)
         } >flash
  __end_of_text__ = .;
  .data : {
         __data_beg__ = .;
         __data_beg_src__ = __end_of_text__;
         *(.data)
         __data_end__ = .;
         } >ram AT>flash
  .bss : {
         __bss_beg__ = .;
         *(.bss)
         } >ram
    /* Align here to ensure that the .bss section occupies space up to
       _end.  Align after .bss to ensure correct alignment even if the
       .bss section disappears because there are no input sections.  */
    . = ALIGN(32 / 8);
   }
   . = ALIGN(32 / 8);
   _end = .;
   _bss_end__ = . ; __bss_end__ = . ; __end__ = . ;
   PROVIDE (end = .);

/*
INPUT( -lc -lgcc)
*/

PROVIDE( undefined_instruction_exception = endless_loop); PROVIDE(
software_interrupt_exception = endless_loop); PROVIDE(
prefetch_abort_exception = endless_loop); PROVIDE( data_abort_exception
= endless_loop); PROVIDE( reserved_exception = endless_loop); PROVIDE(
interrupt_exception = endless_loop); PROVIDE( fast_interrupt_exception =
endless_loop);

PROVIDE( PINSEL0 = 0xE002C000);
PROVIDE( IODIR = 0xE0028008);
PROVIDE( IOCLR = 0xE002800C);
PROVIDE( IOSET = 0xE0028004);

/* UART 0 */

PROVIDE( U0RBR = 0xE000C000);
PROVIDE( U0THR = 0xE000C000);
PROVIDE( U0IER = 0xE000C004);
PROVIDE( U0IIR = 0xE000C008);
PROVIDE( U0FCR = 0xE000C008);
PROVIDE( U0LCR = 0xE000C00C);
PROVIDE( U0LSR = 0xE000C014);
PROVIDE( U0SCR = 0xE000C01C);
PROVIDE( U0DLL = 0xE000C000);
PROVIDE( U0DLM = 0xE000C004);

/* PLL */

PROVIDE( PLLCON = 0xE01FC080);
PROVIDE( PLLCFG = 0xE01FC084);
PROVIDE( PLLSTAT = 0xE01FC088);
PROVIDE( PLLFEED = 0xE01FC08C);

/* MAM */

PROVIDE( MAMCR = 0xE01FC000);
PROVIDE( MAMTIM = 0xE01FC004);

/* VPB */

PROVIDE( VPBDIV = 0xE01FC100);

/* TIMER 0 */

PROVIDE( T0IR = 0xE0004000);
PROVIDE( T0TCR = 0xE0004004);
PROVIDE( T0TC = 0xE0004008);
PROVIDE( T0PR = 0xE000400C);
PROVIDE( T0PC = 0xE0004010);
PROVIDE( T0MCR = 0xE0004014);
PROVIDE( T0MR0 = 0xE0004018);
PROVIDE( T0MR1 = 0xE000401C);
PROVIDE( T0MR2 = 0xE0004020);
PROVIDE( T0MR3 = 0xE0004024);
PROVIDE( T0CCR = 0xE0004028);
PROVIDE( T0CR0 = 0xE000402C);
PROVIDE( T0CR1 = 0xE0004030);
PROVIDE( T0CR2 = 0xE0004034);
PROVIDE( T0EMR = 0xE000403C);


-----END LINKER SCRIPT-----


 


Yahoo! Groups Links

To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2100/

To unsubscribe from this group, send an email to:
lpc2100-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: [lpc2100] More ld script questions..

2004-01-22 by Robert Adsett

At 11:52 AM 1/22/04 -0500, you wrote:

snip

>And then my boot.s would just copy (__ramtext_end__ - __ramtext_beg__)
>bytes from __ramtext_beg_src__ to __ramtext_beg__.
>
>Is this right?

That sounds right.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

RE: [lpc2100] More ld script questions..

2004-01-22 by Bogdan Marinescu

--- James Dabbs <jdabbs@...> wrote:
> Another question, more conceptual.  This ld uses
> named sections, using >
> to say where it will be loaded, and AT> to say where
> it is at the moment
> of reset.  (I think, anyway).  Let's say I also want
> to use
> __attribute__ to define some functions in RAM,
> naming this ".ramtext" in
> my C code.  My guess is that this looks something
> like this:
> 
>   prog : {
>          *(.text)
>          *(.rodata)
>          *(.rodata*)
>          *(.glue_7)
>          *(.glue_7t)
>          __end_of_prog__ = . ;
>          } >flash
> 
>   .ramtext : {
>          __ramtext_beg__ = . ;
>          __ramtext_beg_src__ = __end_of_prog__ ;
>          *(.ramtext)
>          __ramtext_end__ = .;
>          } >ram AT>flash
> 
    I didn't see anybody using "AT" in this way. My
linker script would probably look like this instead:

    .ramtext : AT( ADDR( flash ) + SIZEOF( prog ) )
    {
      /* the rest goes here */
    } > ram

    I'm not saying that your syntax is wrong, I just
never seen it in practice, nor heard of it, so if it
doesn't work you can try the above variant instead.
Another advice (this comes directly from experience):
try to always set the location counter (.) to a
multiple of 4 at the end of the section declaration,
or at least do this for data sections, or you might
have some nasty surprises.     
> And then my boot.s would just copy (__ramtext_end__
> - __ramtext_beg__)
> bytes from __ramtext_beg_src__ to __ramtext_beg__.
> 
> Is this right?
    Almost. This will work for simple examples.
However, things will get much more interesting if you
have pointers to functions in your program. They must
be changed to reflect the new address of your code in
RAM. I'm not exactly sure how GCC handles this, but
you'll need to specify -fPIC for compilation and hope
that the rest of the story is already implemented in
the runtime.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

RE: [lpc2100] More ld script questions..

2004-01-22 by Robert Adsett

At 12:51 PM 1/22/04 -0800, you wrote:
>--- James Dabbs <jdabbs@...> wrote:
> > Another question, more conceptual.  This ld uses
> > named sections, using >
> > to say where it will be loaded, and AT> to say where
> > it is at the moment
> > of reset.  (I think, anyway).  Let's say I also want
> > to use
> > __attribute__ to define some functions in RAM,
> > naming this ".ramtext" in
> > my C code.  My guess is that this looks something
> > like this:
> >
> >   prog : {
> >          *(.text)
> >          *(.rodata)
> >          *(.rodata*)
> >          *(.glue_7)
> >          *(.glue_7t)
> >          __end_of_prog__ = . ;
> >          } >flash
> >
> >   .ramtext : {
> >          __ramtext_beg__ = . ;
> >          __ramtext_beg_src__ = __end_of_prog__ ;
> >          *(.ramtext)
> >          __ramtext_end__ = .;
> >          } >ram AT>flash
> >
>     I didn't see anybody using "AT" in this way. My
>linker script would probably look like this instead:
>
>     .ramtext : AT( ADDR( flash ) + SIZEOF( prog ) )
>     {
>       /* the rest goes here */
>     } > ram

His original syntax is more or less straight out of the ld manual.


>     I'm not saying that your syntax is wrong, I just
>never seen it in practice, nor heard of it, so if it
>doesn't work you can try the above variant instead.
>Another advice (this comes directly from experience):
>try to always set the location counter (.) to a
>multiple of 4 at the end of the section declaration,
>or at least do this for data sections, or you might
>have some nasty surprises.
> > And then my boot.s would just copy (__ramtext_end__
> > - __ramtext_beg__)
> > bytes from __ramtext_beg_src__ to __ramtext_beg__.
> >
> > Is this right?
>     Almost. This will work for simple examples.
>However, things will get much more interesting if you
>have pointers to functions in your program. They must
>be changed to reflect the new address of your code in
>RAM. I'm not exactly sure how GCC handles this, but
>you'll need to specify -fPIC for compilation and hope
>that the rest of the story is already implemented in
>the runtime.

ld should handle that transparently.  All the records that are in FLASH 
will already be located to run from ram.  Now if you try to use them 
directly from flash w/o copying them I would expect problems.

I don't see why position independent code would be needed (it is always 
ending up in the same place and that place is defined at link time).

Robert




>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free web site building tool. Try it!
>http://webhosting.yahoo.com/ps/sb/
>
>
>
>
>Yahoo! Groups Links
>
>To visit your group on the web, go to:
>  http://groups.yahoo.com/group/lpc2100/
>
>To unsubscribe from this group, send an email to:
>  lpc2100-unsubscribe@yahoogroups.com
>
>Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

RE: [lpc2100] More ld script questions..

2004-01-22 by Bogdan Marinescu

> My
> >linker script would probably look like this
> instead:
> >
> >     .ramtext : AT( ADDR( flash ) + SIZEOF( prog )
> )
> >     {
> >       /* the rest goes here */
> >     } > ram
> 
> His original syntax is more or less straight out of
> the ld manual.
    I'm sorry, I must have missed that part of the
manual. Actually I'm still unable to find it.
> ld should handle that transparently.  All the
> records that are in FLASH 
> will already be located to run from ram.  Now if you
> try to use them 
> directly from flash w/o copying them I would expect
> problems.
    You bet :)
> I don't see why position independent code would be
> needed (it is always 
> ending up in the same place and that place is
> defined at link time).
    Of course, you are right; I didn't realize that
the code always ends up in the same place. You only
need PIC if the load address is not known at link
time. I seem to have a strange urge to see things more
complicated than they are tonight, so I'd better go to
sleep ...


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Emdedded Internet With LPC2106

2004-01-22 by gokbektas

Is there any free TCP/IP + PPP stack for LPC210x
series?
If there is not, I'll port Motorola AN2120 to LPC210x
for our development board.
But if there is, I don't want to
waste time.
I need implementation of Modem Dial, PPP
authentification and TCP/IP connection to
ISP.
 
Regards
 

Re: More ld script questions..

2004-01-22 by robertadsett

--- In lpc2100@yahoogroups.com, Bogdan Marinescu
<a_bogdan_marinescu@y...> wrote:
>     I'm sorry, I must have missed that part of the
> manual. Actually I'm still unable to find it.
That I can offer some help with.  Search for (google +gnu +ld +pdf). 
That gets you several links including

http://www.soundart-hot.com/files/pdf/gnu/ld.pdf

Also the cygwin distribution comes with the appropriate man page (as
presumably do most linux distributions).  I don't much care for man
when I'm starting to learn something but it is a start and will work
if you can print it out.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

_call_via_r1, _call_via_r2, etc..

2004-01-22 by James Dabbs

The linker is bitching about these, which I'm sure are ARM<->Thumb
interworking stubs, probably stripped out because of nostartupfiles, or
nostdlib..

I'd like to either (1) get gcc to do these for me, or (2) lift them from
somewhere and drop them in a .s file.  Any guidance would be greatly
appreciated!

-James

RE: [lpc2100] _call_via_r1, _call_via_r2, etc..

2004-01-23 by James Dabbs

For posterity: the solution to this is to link with arm-elf-gcc, and not
directly with arm-elf-ld.

Thanks!
Show quoted textHide quoted text
-----Original Message-----
From: James Dabbs [mailto:jdabbs@...] 
Sent: Thursday, January 22, 2004 5:46 PM
To: lpc2100@yahoogroups.com
Subject: [lpc2100] _call_via_r1, _call_via_r2, etc..


The linker is bitching about these, which I'm sure are ARM<->Thumb
interworking stubs, probably stripped out because of nostartupfiles, or
nostdlib..

I'd like to either (1) get gcc to do these for me, or (2) lift them from
somewhere and drop them in a .s file.  Any guidance would be greatly
appreciated!

-James


 


Yahoo! Groups Links

To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2100/

To unsubscribe from this group, send an email to:
lpc2100-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: [lpc2100] _call_via_r1, _call_via_r2, etc..

2004-01-23 by Bogdan Marinescu

This is what I found on my system:

./lib/gcc-lib/arm-elf/3.1/libgcc.a
_call_via_rX.o:
0000002c T _call_via_fp
00000030 T _call_via_ip
00000038 T _call_via_lr
00000000 T _call_via_r0
.......................
00000024 T _call_via_r9
00000028 T _call_via_sl
00000034 T _call_via_sp
_interwork_call_via_rX.o:
000000e4 T _interwork_call_via_fp
000000f8 T _interwork_call_via_ip
00000120 T _interwork_call_via_lr
00000008 T _interwork_call_via_r0
.................................
000000bc T _interwork_call_via_r9
000000d0 T _interwork_call_via_sl
0000010c T _interwork_call_via_sp
./lib/gcc-lib/arm-elf/3.1/thumb/libgcc.a
_call_via_rX.o:
0000002c T _call_via_fp
00000030 T _call_via_ip
00000038 T _call_via_lr
00000000 T _call_via_r0
.......................
00000024 T _call_via_r9
00000028 T _call_via_sl
00000034 T _call_via_sp
_interwork_call_via_rX.o:
000000e4 T _interwork_call_via_fp
000000f8 T _interwork_call_via_ip
00000120 T _interwork_call_via_lr
00000008 T _interwork_call_via_r0
.................................
000000bc T _interwork_call_via_r9
000000d0 T _interwork_call_via_sl
0000010c T _interwork_call_via_sp

    Simply linking the required library in your
application should do the trick. And it will work with
ld. Whenever you're unsure about the location of a
symbol in the libraries use "nm" together with "grep"
for all the libraries in the GNU directory. If the
symbol is there, "nm" will find it.

--- James Dabbs <jdabbs@...> wrote:
> For posterity: the solution to this is to link with
> arm-elf-gcc, and not
> directly with arm-elf-ld.
> 
> Thanks!
> 
> -----Original Message-----
> From: James Dabbs [mailto:jdabbs@...] 
> Sent: Thursday, January 22, 2004 5:46 PM
> To: lpc2100@yahoogroups.com
> Subject: [lpc2100] _call_via_r1, _call_via_r2, etc..
> 
> 
> The linker is bitching about these, which I'm sure
> are ARM<->Thumb
> interworking stubs, probably stripped out because of
> nostartupfiles, or
> nostdlib..
> 
> I'd like to either (1) get gcc to do these for me,
> or (2) lift them from
> somewhere and drop them in a .s file.  Any guidance
> would be greatly
> appreciated!
> 
> -James
> 
> 
>  
> 
> 
> Yahoo! Groups Links
> 
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/lpc2100/
> 
> To unsubscribe from this group, send an email to:
> lpc2100-unsubscribe@yahoogroups.com
> 
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/ 
> 
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.