2010-10-06 04:16:04     moving the code of some newlib functions to external memory

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2010-10-06 04:16:04     moving the code of some newlib functions to external memory

Frank Lorenz (GERMANY)

Message: 94246   

 

Hi,

 

 

 

I have the following problem (on a bfin-elf bare metal app):

 

My internal program memory is nearly filled up, so I cannot use some standard lib functions like printf without blasting my internal mem code size.

 

When I alter my linker script so the newlib functions are moved into external memory, there are also some low level math functions moved to external mem (e.g. from objects _divsi3.o,  _addsub_df.o, _muldi3.o). Because I use these in some DSP, moving this to external mem breaks performance requirements.

 

 

 

So I'm searching for a way to tell the linker to move only specific parts of the newlib to external mem while keeping these low level math objects in internal mem. Is there any?

 

 

 

best regards,

 

Frank

TranslateQuoteReplyEditDelete

 

 

2010-10-06 04:39:12     Re: moving the code of some newlib functions to external memory

Mike Frysinger (UNITED STATES)

Message: 94249   

 

have you read the linker manual ?

http://sourceware.org/binutils/docs/ld/

 

in particular, you'll want to review the Input Section documentation:

http://sourceware.org/binutils/docs/ld/Input-Section.html

 

it tells you how to match specific sections/objects/functions

QuoteReplyEditDelete

 

 

2010-10-06 05:41:30     Re: moving the code of some newlib functions to external memory

Frank Lorenz (GERMANY)

Message: 94257   

Hi Mike,

 

yes, I read it. But up to now, I did not manage to move single files to external mem.

 

I have attached my linker script which is derived from the standard linker script. Please look for memory section MEM_EXTERNAL_CODE and output section .ext.code.

 

(I already moved parts of my own code to .ext.code by using gcc's __attribute__ functionality).

 

When I try to move a single file like strncpy from libc.a to .ext.code like this:

 

  .ext.code       : { strncpy.o *(.ext.code) } > MEM_EXTERNAL_CODE

 

I get a linker error:

 

 

bfin-elf-gcc -o panelG2.elf -g -mcpu=bf537 -Wall -TpanelG2.ld -Wl,-Map panelG2.map Initialization.o ISRs.o main.o dma.o errors.o helpers.o tty.o uart.o dbg_terminal.o dsp.o spi.o ad1939.o cs4270.o gpi.o ports.o sport.o audio.o tests.o m29w320.o flash.o i2c.o  cs8416.o cs8406.o aes_if.o timer.o sebu.o sebu_phy.o frontcomm_phy.o frontcomm.o  state.o daughtercard.o portexpander.o display4000.o keys4000.o firmware.o user_interface.o frontcomm_bootldr.o common_code/crc.o common_code/sebucmd.o testmode.o

/opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/bin/ld.real: cannot find strncpy.o

 

 

What am I doing wrong?

 

 

 

linkerscript_FL.ld

TranslateQuoteReplyEditDelete

 

 

2010-10-06 09:46:35     Re: moving the code of some newlib functions to external memory

Mike Frysinger (UNITED STATES)

Message: 94273   

 

if you dont have a file named "strncpy.o" in $PWD, then your input section filter is incorrect

 

assuming you're trying to grab the strncpy.o from newlib's libc.a, you need to match the C library archive as detailed in Input Section Basics, and you probably need to use a wildcard in its path name as detailed in Input Section Wildcards

 

keep in mind that the first match reached is the one used regardless of what comes later in the script

QuoteReplyEditDelete

 

 

2010-10-06 10:11:59     Re: moving the code of some newlib functions to external memory

Frank Lorenz (GERMANY)

Message: 94277   

 

Hi Mike,

 

thanks for the tips, I am now able to move strncpy when I put the following line in the linker file:

 

 

 

.ext.code       :

 

  {

 

    strncpy*(.text)

 

    *(.ext.code)

 

  } > MEM_EXTERNAL_CODE

 

 

 

But I did not find a valid name for the archive ( i tried "libc.a", "libc", "c", even "*libc*" and "*c*") to issue the input section in a way like "libc.a:strncpy*

 

 

 

A more severe problem is, that when I try to move malloc / free, to external memory I get "relocation truncated to fit" errors:

 

/opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mallocr.o): In function `_malloc_r':

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2352: relocation truncated to fit: R_pcrel24 against symbol `___malloc_lock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2441: relocation truncated to fit: R_pcrel24 against symbol `___malloc_unlock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2497: relocation truncated to fit: R_pcrel24 against symbol `___malloc_unlock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2584: relocation truncated to fit: R_pcrel24 against symbol `___malloc_unlock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mallocr.o): In function `malloc_extend_top':

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2160: relocation truncated to fit: R_pcrel24 against symbol `__sbrk_r' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(sbrkr.o)

 

/opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mallocr.o): In function `_malloc_r':

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2574: relocation truncated to fit: R_pcrel24 against symbol `___malloc_unlock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2506: relocation truncated to fit: R_pcrel24 against symbol `___malloc_unlock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mallocr.o): In function `malloc_extend_top':

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:2197: relocation truncated to fit: R_pcrel24 against symbol `__sbrk_r' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(sbrkr.o)

 

/opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(freer.o): In function `_malloc_trim_r':

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:3312: relocation truncated to fit: R_pcrel24 against symbol `___malloc_lock' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(mlock.o)

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:3326: relocation truncated to fit: R_pcrel24 against symbol `__sbrk_r' defined in .text section in /opt/uClinux/bfin-elf/lib/gcc/bfin-elf/4.1.2/../../../../bfin-elf/lib/libc.a(sbrkr.o)

 

/usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/newlib/libc/stdlib/mallocr.c:3348: additional relocation overflows omitted from the output

 

collect2: ld gab 1 als Ende-Status zurück

 

make: *** [panelG2.elf] Fehler 1

 

 

 

Can I omit this truncations, or do I have to take care that all functions that call each others reside "near to each other" in memory?

TranslateQuoteReplyEditDelete

 

 

2010-10-06 10:31:25     Re: moving the code of some newlib functions to external memory

Mike Frysinger (UNITED STATES)

Message: 94279   

 

seems the archive syntax is not supported in the old version of binutils we're shipping atm (2.17).  so you will have to stick with the wildcard.

 

i imagine newlib is not compiled with -mlong-calls which means you need to relocate related sections of code together (all the malloc), or place your MEM_EXTERNAL_CODE at the bottom of memory (below the 16MiB address) so that PCREL24 relocations can reach L1 text.

QuoteReplyEditDelete

 

 

2010-10-06 10:51:33     Re: moving the code of some newlib functions to external memory

Frank Lorenz (GERMANY)

Message: 94283   

 

O.k., thanks, that clarifies some things for me.

 

I got rid of the relocation errors by putting the MEM_EXTERNAL_CODE section below the 16 MB boundary.

 

 

Because archive syntax does not work, there is no easy way for me to put the whole libc.a stuff to external mem, right? (My idea was to put all of this to external mem and only put some "performance relevant code" back into internal mem)

TranslateQuoteReplyEditDelete

 

 

2010-10-06 11:01:09     Re: moving the code of some newlib functions to external memory

Mike Frysinger (UNITED STATES)

Message: 94287   

 

you're probably right.  but if that's your desire, it'd probably make more sense to invert your section usage.  put all .text into external memory and label the few functions you want with standard l1_text attributes.

QuoteReplyEditDelete

 

 

2010-10-07 04:26:31     Re: moving the code of some newlib functions to external memory

Frank Lorenz (GERMANY)

Message: 94310   

 

Yes, this is what I feared: I have to inverse the setting.

 

Because my project grew over time, it has a lot of functions which are pushed to external memory explicitely through __attribute__ ((section(".ext.code")))

 

This means approx. one day of work for me for removing this, adding some kind of ".internal.code" section, move the "performance relevant functions" into this section and test the new configuration to ensure that all works well.

 

Wouldn't it be good to add some documentation about this issue? Looking back to the beginning of the project, it would have been very easy to configure the linker to put all things by default into external memory -- but because there's a lack of documentation about bfin-elf based bare metal apps, I had to learn it the hard way...

 

 

 

best regards,

 

Frank

TranslateQuoteReplyEditDelete

 

 

2010-10-07 11:33:17     Re: moving the code of some newlib functions to external memory

Mike Frysinger (UNITED STATES)

Message: 94315   

 

-ffunction-sections and -fdata-sections would automatically create a unique section for every function and data object

Attachments

Outcomes