Libgcc.a in .frodata section legen

[Reinhard Kager (Gast)]

Hallo Board,

i verwende das KPIT GNU Package für meinen R8C Renesas Controller. 
Dieses verwendet den gcc4.5 als compiler.

Ich habe folgendes Problem. Aus irgendeinem Grund unterstützt das KPIT 
package nicht far pointer in den 32bit Bereich (.frodata section ab 
0x10000). Funktionen können von dort aber ausgeführt werden. Das 
bedeutet ich muss meine ganzen const data (statische Elemente für 
display Ausgabe, Texte, bmps usw) in den .text Bereich legen und die 
Funktionen in den .frodata Bereich.
Das funktioniert auch prima mit all meinen selbst geschriebenen 
Funktionen. Nur benötigen die Funktionen aus der libgcc noch Speicher in 
der .text Section welche ich aber für weitere const data benötige.

Frage: Kann man den Linker mitteilen die Funktionen aus der libgcc in 
den .frodata Bereich zu legen?

  .frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    "C:\program files\renesas\hew\tools\kpit\gnurx-elf\v12.01\rx-elf\rx-elf\lib\libgcc.a" (P .text .comment)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }

funktioniert einmal nicht.

Vielen Dank für die Hilfe ist wirklich sehr wichtig, da ich ansonsten 
komplett die CPU Familie wechseln muss!

Reinhard

[Johann L. (gjlayde)]

Schluckt ds Linkerscript Bibliotheken?

  .frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    libgcc.a(.text.*)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }

 
Falls es nur Objekte nimmt, dann:
 

  .frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    __*.o(.text.*)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }

 
Evtl ist auch text / rodata anzupassen, damit die ensprechenden 
Inpot-Sections dort nicht mehr auftauchen (z.B. wenn die vor .frodata 
stehen).

Ergebnis per Map-File kontrollieren.

Übrigens willst du .comment nicht im Flash haben!

[Reinhard Kager (Gast)]

Danke Johann für deine schnelle Antwort!

Habe jetzt folgendes ausprobiert:

    .frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    libgcc.a(P .text.* .comment)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }
  .text 0x00003000 : AT (0x00003000)
  {
      *(.text) 
      *(.text.*) 
      etext = .; 
  }

Auch ohne P und .comment. Zusätzlich habe ich es erstmal vor die .text 
Section gestellt, aber es funktioniert leider nicht.

In einem anderen Forum meinte sie einmal folgendes:

>Looking at libgcc.a I see that .text entries are in .text.libgcc rather than just 
>plain .text,

Kann das irgendwie reinspielen?

[Reinhard Kager (Gast)]

Hat da vielleicht noch jemand einen Hinweis?

[pegel (Gast)]

Ich habe für den STM32/GCC etwas mit dem linker-script gespielt.

Hab den 128k Speicher in zwei mal 64k geteilt und das komplette *(.text) 
in den oberen Bereich gelegt. Im unteren liegen wie gehabt die 
Vectortabelle und meine main.o.
Zum Test hab ich die Funktion sprintf() benutzt.
Der Aufruf der Funktion im oberen Bereich aus der main klappt und im 
unteren Bereich ist nur etwas "Kleinkram" aus der libc.

Ist natürlich eine ganz andere Familie, aber eben auch ein gcc.

Wenn es nicht funktioniert, nicht hauen ;-)

[Reinhard Kager (Gast)]

Morgen pegel,

also die Funktionen laufen ja schon im oberen Bereich, hab nur das 
Problem, dass ich keine far Pointer auf const daten in den oberen 
Bereich machen kann und das der Kleinkram (libgcc & string methodes) aus 
der lib run 18k braucht?!



Reinhard

[pegel (Gast)]

Reinhard Kager schrieb:
> 18k

Ui.
Ich habe neben der sprintf jetzt noch die printf aus der lib und eine 
eigene Funktion probiert.
Der Abschnitt für die Aufrufe der libc bleibt aber gleich.
Ausschnitte aus dem map file:

Memory Configuration
Name             Origin             Length             Attributes
ram              0x20000000         0x00002000         xrw
rom1             0x08000000         0x00010000         xr
rom2             0x08010000         0x00010000         xr
.
.
.text1          0x08000000      0x698
 *(vectors)
 vectors        0x08000000       0x10 main.o
                0x08000000                myvectors
 main.o()
 .text          0x08000010        0x0 main.o
 .data          0x08000010        0x0 main.o
 .bss           0x08000010        0x0 main.o
 .rodata        0x08000010        0x4 main.o
 .text.main     0x08000014       0x44 main.o
                0x08000014                main
 .text.nmi_handler
                0x08000058        0xc main.o
                0x08000058                nmi_handler
 .text.hardfault_handler
                0x08000064        0xc main.o
                0x08000064                hardfault_handler
 .debug_info    0x08000070      0x120 main.o
 .debug_abbrev  0x08000190       0xa4 main.o
 .debug_loc     0x08000234       0x92 main.o
 .debug_aranges
                0x080002c6       0x30 main.o
 .debug_ranges  0x080002f6       0x20 main.o
 .debug_line    0x08000316       0x70 main.o
 .debug_str     0x08000386       0xc1 main.o
                                 0xfa (size before relaxing)
 .comment       0x08000447       0x11 main.o
                                 0x12 (size before relaxing)
 .ARM.attributes
                0x08000458       0x31 main.o
 *fill*         0x08000489        0x3 00
 .debug_frame   0x0800048c       0x60 main.o
 .iplt          0x00000000        0x0 main.o
 .rel.iplt      0x00000000        0x0 main.o
 .igot.plt      0x00000000        0x0 main.o
 *(.rodata)
 .rodata        0x080004ec       0x20 /lib/libc.a(lib_a-svfprintf.o)
 .rodata        0x0800050c       0x20 /lib/libc.a(lib_a-vfprintf.o)
 .rodata        0x0800052c        0x4 /lib/libc.a(lib_a-impure.o)
                0x0800052c                _global_impure_ptr
 .rodata        0x08000530      0x128 /lib/libc.a(lib_a-mprec.o)
                0x08000540                __mprec_tens
                0x08000608                __mprec_tinytens
                0x08000630                __mprec_bigtens
 .rodata        0x08000658       0x20 /lib/libc.a(lib_a-svfiprintf.o)
 .rodata        0x08000678       0x20 /lib/libc.a(lib_a-vfiprintf.o)

.text2          0x08010000     0x88a4
 myf.o()
 .text          0x08010000        0x8 myf.o
                0x08010000                meinefunktion
 .data          0x08010008        0x0 myf.o
 .bss           0x08010008        0x0 myf.o
 .comment       0x08010008       0x11 myf.o
                                 0x12 (size before relaxing)
 .ARM.attributes
                0x08010019       0x31 myf.o
 *(.text)
 *fill*         0x0801004a        0x2 00
 .text          0x0801004c       0x4c /lib/libc.a(lib_a-printf.o)
                0x0801004c                _printf_r
                0x0801006c                printf
 .text          0x08010098       0x94 /lib/libc.a(lib_a-sprintf.o)
                0x08010098                _sprintf_r
                0x080100dc                sprintf
 .text          0x0801012c     0x12c8 /lib/libc.a(lib_a-svfprintf.o)
                0x0801012c                _svfprintf_r
usw.

Der Bereich von 0x080004ec bis 0x08000678 hat sich nach dem zusätzlichen 
benutzen der printf() Funktion nicht verändert.
Vielleicht kannst Du in deinem map file herausfinden was da so viel 
Speicher verbraucht.

[pegel (Gast)]

Hab noch mal mit const probiert. Sobald ein .h file eigebunden wird das 
(globale) const enthält landen die im unteren Bereich. Ich habe keine 
Möglichkeit gefunden die in den oberen zu bringen :-(
Auch nicht mit
__attribute__((section(".text2"))) char meldung2[] = ...
o.ä.

Das Einzige was hilft ist die nicht unbedingt globalen Variablen in die 
.c
Datei zu packen und durch eine Funktion von dort aufzurufen dann bleiben 
sie oben. In meinem Fall in der myf.o .

Aus meiner Sicht sehe ich keine Möglichkeit ohne Veränderung der libc 
bzw. libgcc.

Aber andere wissen vermutlich mehr als ich ;-)

[Roland H. (batchman)]

Reinhard Kager schrieb:
>>Looking at libgcc.a I see that .text entries are in .text.libgcc rather than 
just
>>plain .text,
>
> Kann das irgendwie reinspielen?

Hast Du probiert, dies in Johanns Beispiel einzubauen?

Nach dem Motto

.frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    libgcc.a(.text.libgcc.*)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }

Unabhängig davon zwei weitere Ideen. Die würde ich gehen, wenn die Zeit 
drängt.

- KPIT baut auf der newlib auf. Ich würde die benötigten Funktionen dem 
dortigen Source entnehmen, und direkt einbinden (d. h. ohne newlib), 
einfach mitkompilieren) - bitte aber ggf. die Lizenzbedingungen 
beachten.

- Von wie vielen Funktionen reden wir überhaupt? Ich habe aus diversen 
Gründen heraus mir für alle benötigten Funktionen einen eigenen Ersatz 
geschaffen. Das ist i. d. R. schlanker (printf & Co), besser (itoa ohne 
Puffer mit direktem Streaming), bei ARM gibt es keine Probleme mit den 
multilibs und man muss nicht _sbrk oder _getpid implementieren :-). Ist 
längerfristiger angelegt, hat sich inzwischen amortisiert.

[Roland H. (batchman)]

Nachtrag zu meinen beiden Ideen: Je nach Optimerungsstufe (z. B. -Os) 
streut der GCC in manchen Fällen memcpy() oder memset() ein. Dann wird 
es "undeterministisch".

Frage an Johann: Gibt es eine Möglichkeit, dem GCC mitzuteilen, dass er 
dies nicht machen soll? Wenn ich mich recht entsinne, hilft -nostdlib 
nicht.

[pegel (Gast)]

Hab noch eine weitere Möglichkeit gefunden:
die Funktionen der libc u.a. garnicht direkt in der main() aufrufen 
sondern Funktionen in der oberen (.text) section benutzen die das 
erledigen.
Diese dann in der main aufrufen.
Dann verschwindet sogar der "Kleinkram" aus dem unteren Bereich und man 
hat viiiieeel Platz...

[Reinhard Kager (Gast)]

Hallo,

vielen Dank für die Anteilnahme an meinem Problem ;-)

anbei das genaue Listing der Lib Funktionen welche sich nicht verlegen 
lassen.
Ich will es eigentlich vermeiden mich in die Tiefen des Compilers rein 
zu arbeiten. Da das Projekt eigentlich vom Kunden (an mehreren PCs) 
programmiert wird, dh. ich muss dann alle Installationen immer selbst 
verwalten. Sonst sag ich ihm installier das von dieser Website.. 
Abgesehen von der komplexen Aufgabe selbst..

Das ist ein Auszug aus dem .frodata mapping:

.frodata        0x00010000    0x103d3
                0x00010000                _frodata = .
 libgcc.a(.text.libgcc.*)
 *(.frodata)
 .frodata       0x00010000      0x3ca D:\Technik\Release\SYS_sci.o
                0x00010000                UART1_Init
                0x00010044                UART1_Send_Byte
                0x00010089                UART1_Send_String
                0x000100e1                UART1_SendIntAsString
                0x000101a1                _uart1_receive
                0x000101dc                charOnUART1
                0x000101e0                getCharUART1
                0x00010218                uart_clearRxBuffer
                0x0001021f                _uart1_trance
                0x0001026d                UART2_Init
                0x000102b8                dtc_enable
                0x00010323                transmit_dataViaDTC_UART2
                0x00010387                _uart2_trance
[\code]

In der SYS_sci.o hab ich die section information der jeweiligen Funktion extra angeführt, 
die legt er dann brav dort hin. Was mich etwas verwundert ist,
dass er bei allen libs schön den ganzen Pfad angibt also müsst es vielleicht so gehen:

[code]
.frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    c:\program files (x86)\renesas\hew\tools\kpit cummins\gnum16cm32c-elf\v11.01\m32c-elf\lib\gcc\m32c-elf\4.5-GNUM16CM32C_v11.01\libgcc.a(.text.libgcc.*)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }
[\code]

Da schreit der Linker dann aber 
"m32c-elf-ld.exe: cannot find files" 
weiß wer wie man das vielleicht sonst noch angeben könnte??

Danke auf jeden Fall


Das sind noch meine ganzen libFunktionen.. deshalb die 16k
[code]
  .text          0x0000309c        0x0 libgcc.a(__m32c_memregs.o)
 .text          0x0000309c       0x2d libgcc.a(__m32c_mulsi3.o)
                0x0000309c                __mulsi3
 .text          0x000030c9      0x2d0 libgcc.a(__m32c_subsf3.o)
                0x000030c9                __subsf3
                0x000030d4                __addsf3
 .text          0x00003399       0xfc libgcc.a(__m32c_mulsf3.o)
                0x00003399                __mulsf3
 .text          0x00003495       0x1c libgcc.a(__m32c_jsri16.o)
                0x00003495                m32c_jsri16
 .text          0x000034b1       0x96 libgcc.a(_fixunssfsi.o)
                0x000034b1                __fixunssfsi
 .text          0x00003547      0x1da libgcc.a(_div_sf.o)
                0x00003547                __divsf3
 .text          0x00003721       0x71 libgcc.a(_eq_sf.o)
                0x00003721                __eqsf2
 .text          0x00003792       0x71 libgcc.a(_gt_sf.o)
                0x00003792                __gtsf2
 .text          0x00003803       0x71 libgcc.a(_ge_sf.o)
                0x00003803                __gesf2
 .text          0x00003874       0x71 libgcc.a(_lt_sf.o)
                0x00003874                __ltsf2
 .text          0x000038e5       0x71 libgcc.a(_le_sf.o)
                0x000038e5                __lesf2
 .text          0x00003956       0xf8 libgcc.a(_si_to_sf.o)
                0x00003956                __floatsisf
 .text          0x00003a4e       0xb7 libgcc.a(_sf_to_si.o)
                0x00003a4e                __fixsfsi
 .text          0x00003b05        0x0 libgcc.a(_thenan_sf.o)
 .text          0x00003b05      0x14c libgcc.a(_usi_to_sf.o)
                0x00003b05                __floatunsisf
 .text          0x00003c51      0xa4d libgcc.a(_addsub_df.o)
                0x0000458d                __adddf3
                0x00004612                __subdf3
 .text          0x0000469e      0x898 libgcc.a(_mul_df.o)
                0x0000469e                __muldf3
 .text          0x00004f36      0x449 libgcc.a(_div_df.o)
                0x00004f36                __divdf3
 .text          0x0000537f       0x89 libgcc.a(_lt_df.o)
                0x0000537f                __ltdf2
 .text          0x00005408      0x11a libgcc.a(_si_to_df.o)
                0x00005408                __floatsidf
 .text          0x00005522       0xb7 libgcc.a(_df_to_si.o)
                0x00005522                __fixdfsi
 .text          0x000055d9        0x0 libgcc.a(_thenan_df.o)
 .text          0x000055d9      0x1b6 libgcc.a(_usi_to_df.o)
                0x000055d9                __floatunsidf
 .text          0x0000578f      0x455 libgcc.a(m32c-lib2.o)
                0x0000578f                udivmodsi4
                0x0000588e                __divsi3
                0x00005902                __modsi3
                0x000059e0                __ffshi2
                0x00005a61                __clzhi2
                0x00005af0                __ctzhi2
                0x00005b65                __popcounthi2
                0x00005b85                __parityhi2
                0x00005ba8                __udivsi3
                0x00005bc5                __umodsi3
 .text          0x00005be4      0x255 libgcc.a(_muldi3.o)
                0x00005be4                __muldi3
 .text          0x00005e39      0x153 libgcc.a(_lshrdi3.o)
                0x00005e39                __lshrdi3
 .text          0x00005f8c      0x16c libgcc.a(_ashldi3.o)
                0x00005f8c                __ashldi3
 .text          0x000060f8        0x0 libgcc.a(_clz.o)
 .text          0x000060f8       0xa7 libgcc.a(_clzsi2.o)
                0x000060f8                __clzsi2
 .text          0x0000619f        0x0 libgcc.a(_popcount_tab.o)
 .text          0x0000619f      0x324 libgcc.a(_pack_sf.o)
                0x0000619f                __pack_f
 .text          0x000064c3       0xf2 libgcc.a(_unpack_sf.o)
                0x000064c3                __unpack_f
 .text          0x000065b5       0x91 libgcc.a(_fpcmp_parts_sf.o)
                0x000065b5                __fpcmp_parts_f
 .text          0x00006646      0x712 libgcc.a(_pack_df.o)
                0x00006646                __pack_d
 .text          0x00006d58      0x1df libgcc.a(_unpack_df.o)
                0x00006d58                __unpack_d
 .text          0x00006f37       0xe1 libgcc.a(_fpcmp_parts_df.o)
                0x00006f37                __fpcmp_parts_d
 .text          0x00007018       0x74 liboptc.a(atoi.o)
                0x00007018                atoi
 .text          0x0000708c       0x2d liboptc.a(memcpy.o)
                0x0000708c                memcpy
 .text          0x000070b9       0x2e liboptc.a(sprintf.o)
                0x000070c4                sprintf
 .text          0x000070e7       0x20 liboptc.a(strcat.o)
                0x000070e7                strcat
 .text          0x00007107       0x14 liboptc.a(strlen.o)
                0x00007107                strlen
 .text          0x0000711b       0x3a liboptc.a(strncat.o)
                0x0000711b                strncat
 .text          0x00007155       0x3c liboptc.a(strncmp.o)
                0x00007155                strncmp
 .text          0x00007191       0x38 liboptc.a(strncpy.o)
                0x00007191                strncpy
 .text          0x000071c9       0x41 liboptc.a(strstr.o)
                0x000071c9                strstr
 .text          0x0000720a       0x16 liboptc.a(toupper.o)
                0x0000720a                toupper
 .text          0x00007220      0xfd7 liboptc.a(frmwri.o)
                0x00007220                _formatted_write
 .text          0x000081f7       0x89 libgcc.a(_ne_df.o)
                0x000081f7                __nedf2
 .text          0x00008280       0x89 libgcc.a(_ge_df.o)
                0x00008280                __gedf2
 .text          0x00008309       0x89 libgcc.a(_le_df.o)
                0x00008309                __ledf2
 *(.text.*)

[Reinhard Kager (Gast)]

Sorry, falscher Formatierungscode!

Anbei mein Vorschlag noch einmal der "m32c-elf-ld.exe: cannot find 
files" produziert.

.frodata 0x00010000 : AT (0x00010000)
  {
    _frodata = .;
    c:\program files (x86)\renesas\hew\tools\kpit cummins\gnum16cm32c-elf\v11.01\m32c-elf\lib\gcc\m32c-elf\4.5-GNUM16CM32C_v11.01\libgcc.a(.text.libgcc.*)
    *(.frodata)
    *(.frodata.*)
    _efrodata = .;
  }

[pegel (Gast)]

Na ja, wie gesagt: wenn Du in der main ein #include <stdio.h> o.ä. 
aufrufst kommt alles Mögliche auch direkt mit rein. Egal wo die libgcc 
im Speicher liegt.

Ich wäre dafür die ausgelagerten Funktionen zu benutzen.

[Reinhard Kager (Gast)]

Das es mit rein kommt stört mich ja nicht, ich will es aber in den 
.frodata legen, da ich keine const data dort hinlegen kann!

[Reinhard Kager (Gast)]

Aber das mit den ausgelagerten Funktionen ist vielleicht eine Idee!

[pegel (Gast)]

Reinhard Kager schrieb:
> Das es mit rein kommt stört mich ja nicht, ich will es aber in den
> .frodata legen,

Genau das ist es ja. Wenn Du die ausgelagerten Funktionen in den 
.frodata Bereich legst und nur dort die stdio.h u.a. in die .c Datei 
einbinest bleibt alles "oben". Nur nicht die stdio.h u.a. schon in der 
oberen .h einbinden, sonst ist alles wieder "unten".

[Reinhard Kager (Gast)]

Also.. die string.h Funktionen sollten nicht das Problem sein, werden 
Euren Vorschlag aufgreifen und meine eigene string.c mit

char *my_strncat (char *dest, const char *src, unsigned long maxlen);

usw.

erstellen und die Dinger per Attribute in den .frodata schieben. Leider 
bringt mir das nur rund 0,5kB. Viel mehr Platz brauchen die

__addsf3 
__mulsf3
__clzhi2
__nedf2
usw.

das sind rund 18kB?!
Da werd ich wohl nicht rumkommen und versuch mir meine eigene lib zu 
erstellen welche ich gleich mit der section information versehe und 
binde diese händisch ein. Klingt einfach :/

Reinhard

[Roland H. (batchman)]

> __addsf3
> __mulsf3
> __clzhi2
> __nedf2

Oops. Das klingt nicht so toll. Verwendest Du float/uint32_t/uint64_t? 
Oder aus welcher Ecke kommen die ersten beiden? Oder hat die CPU z. B. 
keinen "HW multiplier"?

Reinhard Kager schrieb:
> 18kB?!

Hmm. Wenn es um diese Größenordnung geht, dann steckt doch mehr 
dahinter.

Bevor Du diesen Weg einschlägst, probiere doch vorher mal ein "leeres" 
Programm, damit Du siehst, welche Dinge er grundsätzlich einbindet. Dann 
ggf. schrittweise float/uint16_t/uint32_t/uint64_t etc. hinzunehmen. 
Diese Dinge könnten Probleme bereiten.

Wie schon bei memset/memcpy erwähnt: Wenn der Compiler sich implizt bei 
der Bibliothek bedient, dann könnte es haarig werden.

[Johann L. (gjlayde)]

Roland H. schrieb:
> Nachtrag zu meinen beiden Ideen: Je nach Optimerungsstufe (z. B. -Os)
> streut der GCC in manchen Fällen memcpy() oder memset() ein. Dann wird
> es "undeterministisch".
>
> Frage an Johann: Gibt es eine Möglichkeit, dem GCC mitzuteilen, dass er
> dies nicht machen soll?

Ja, indem man MOVE_RATIO, SET_RATIO, CLEAR_RATIO, etc. entsprechend 
setzt (z.B. vom neuen Optionen abhängig macht) und GCC damit generiert 
;-)

Evtl. wird -Os / nicht -Os schon berücksichtigt, hängt vom Target ab.

> Wenn ich mich recht entsinne, hilft -nostdlib nicht.

Das wirkt auf den Linker-Aufruf, nicht auf die Codeerzeugung durch den 
Compiler.

[Reinhard Kager (Gast)]

Hallo..

ja werd ich ASAP versuchen, mein Problem ist halt, dass die Applikation 
ein Kunde schreibt und ihn kann ich nur schwer beibringen keine floats 
usw. zu verwenden...

Aber zum Glück haben wir bei der HW Entwicklung 10 Euro für den teureren 
Controller gespart :/

Reinhard

[Roland H. (batchman)]

Reinhard Kager schrieb:
> kann ich nur schwer beibringen keine floats
> usw. zu verwenden

M. E. ist dann der Versuch, die Funktionen aus der newlib 
herauszunehmen, deutlich schwieriger. Da wird doch fast wieder das 
"linker script" attraktiv.

> Aber zum Glück haben wir bei der HW Entwicklung 10 Euro für den teureren
> Controller gespart

Du hast unsere Rechnungen vergessen :-)

Und es gibt so viele schöne 32-Bit MCUs: PIC32, Renesas RX, ARMs ;-)

[Reinhard Kager (Gast)]

Morgen,

ja eigentlich werden für neue Projekte nur mehr die RX eingesetzt (RX62N 
oder T) aber das war so ein preis sensibles Projekt.. Aber für den 
Mehraufwand hier müssen sie schon wieder ein paar Stück verkaufen.. 
c'est la vie