2017-06-19 51 views
6

Mam aplikacji, która działa na gołej tarczy metalowej i ma następującą strukturęDynamicznie kod obciążenie wbudowanego cel

  • main.c
  • service.c/.h

To skompilowaną do pliku wykonywalnego ELF (system.elf) przy użyciu standardowej sekwencji gcc -c, ld. Używam linkera do wygenerowania pliku mapy z adresami wszystkich symboli.

Teraz, bez ponownego flashowania mojego systemu, muszę dodać dodatkową funkcjonalność za pomocą niestandardowego programu ładującego. Pamiętaj, to jest bare-metal bez systemu operacyjnego.

Chciałbym

  • kompilacji extra.c która wykorzystuje API zdefiniowane w service.h (i jakoś połączyć przeciwko istniejącym service.o/system.elf)
  • skopiować powstały wykonywalny do mojego SDRAM przy starcie i skok do niego
  • kod załadowany powinien być w stanie uruchomić i dostęp eksportowane symbole z service.c jak oczekiwano

i tho ught byłbym w stanie ponownie wykorzystać plik mapy połączyć extra.o przeciwko system.elf ale to nie działa:

ld -o extraExe extra.o system.map 

Czy gcc lub ld mieć jakiś tryb, aby ten późnego powiązania? Jeśli nie, w jaki sposób mogę uzyskać dynamiczne ładowanie kodu, które opisałem powyżej?

+1

gcc nie jest alinker. – Olaf

+0

naprawiono tytuł, usuwano -1, lub po prostu dawałem wydajną odpowiedź :) –

+1

Nadal jest to frontend do linkera, więc możesz połączyć za pomocą gcc ... –

Odpowiedz

4

Można użyć nazwy pliku "-R " "lub" --just-symbols = nazwa pliku "opcje polecenia w ld. Odczytuje nazwy symboli i ich adresy od nazwy pliku, ale nie przenosi go ani nie umieszcza w wynikach. Dzięki temu plik wyjściowy będzie symbolicznie odnosił się do absolutnych lokalizacji pamięci zdefiniowanych w programie system.elf. (patrz ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html).

Tak tutaj nazwa pliku będzie "system.elf". Można skompilować extra.c z GCC normalnie w tym services.h ale bez powiązania i generować „extra.o” następnie wywołać ld jak poniżej:

ld -R"system.elf" -o"extra.out" extra.o 

The „extra.out” mają twoi symbole związane. Możesz użyć programu objdump do porównania zawartości zarówno "extra.out", jak i "extra.o". Należy pamiętać, że zawsze można przekazać adres początkowy programu do ld (np. -defsym _TEXT_START_ADDR = 0xAAAA0123), a także adres początkowy innych sekcji pamięci, takich jak bss, dane. (tj. -Tbss, -Tdata)
Uważaj, aby użyć prawidłowego adresu, który nie jest w konflikcie z "system.elf", ponieważ ld nie wygeneruje błędu. Możesz zdefiniować nowe obszary załadowanego kodu + dane + bss w oryginalnym skrypcie linkera i ponownie skompilować plik system.elf, a następnie wskazać adresy początkowe do zdefiniowanych obszarów, jednocześnie łącząc "extra.o".