Když se GAS ELF směrnic .type, .thumb, .size a .section potřeba?

hlasů
13

Pracuji na běžícím programu pro ARM Cortex-M3 na bázi mikroprocesoru (Thumb 2 instrukční sady) s použitím GNU as.

V některých příkladu kódu považuji směrnic, jako je .size, .sectiona .typekteré chápu tak ELF směrnic. Jako příklad:

    .section    .text.Reset_Handler
    .weak       Reset_Handler
    .type       Reset_Handler, %function  
Reset_Handler:
    bl      main
    b       Infinite_Loop    
    .size   Reset_Handler, .-Reset_Handler



.typeSměrnice je prý nastavit typ symbolu - obvykle buď% objektu (tzn data?) Nebo% funkce. Nevím, jaký rozdíl to dělá. To není vždy zahrnuta v ceně, takže jsem si jistý, kdy je třeba použít.

Souvisí také se jedná o .thumb_funcsměrnici. Z toho, co jsem četl, že se zdá, jako by to mohlo být ekvivalent:

.thumb 
.type Symbol_Name, %function

Nebo je to něco úplně jiného?



.sizeúdajně nastavuje velikost spojený se symbolem. Je-li to nezbytné, nemám tušení. Je to počítáno jako výchozí, ale overrideable s touto směrnicí? Pokud ano - kdy chcete přepsat?



.sectionJe snazší najít dokumenty týkající se a myslím, že mám jasnou představu o tom, co to dělá , ale já jsem ještě trochu nejistý o použití. Jak jsem pochopil, že se přepíná mezi různými ELF úseky ( textpro kód, datapro zapisovatelné dat, bsspro neinicializované dat, rodatakonstant, a další), a definuje nové, když je to žádoucí. Myslím, že byste přepínat mezi nimi v závislosti na tom, zda můžete definovat kód, data, neinicializované dat, atd Ale proč byste měli vytvořit podsekce pro funkci, jako ve výše uvedeném příkladu?


ocení Jakákoli pomoc s tímto. Pokud můžete najít odkazy na výukové programy nebo dokumenty, které vysvětlují to ve větším detailu - nejlépe pochopitelné pro nováčky - byl bych velmi vděčný.

Zatím Použití jako ruční bylo trochu pomoci - možná byste mohli získat více z ní než já, s více znalostí.

Položena 12/12/2010 v 19:24
zdroj uživatelem
V jiných jazycích...                            


3 odpovědí

hlasů
10

Byl jsem programování ramene / palec po mnoho let hodně assembleru a potřebovali jen velmi málo z mnoha směrnic venku.

.thumb_func je velmi důležité, jak poukázal jiným responder.

například

.globl _start
_Start:
    b resetu

resetovat:

.paže

.globl jeden
jeden:
    přidat R0, R0, # 1
    bx lr

.palec

.globl dva
dva:
    přidat R0, R0, # 2
    bx lr

.thumb_func
.globl tři
tři:
    přidat R0, R0, # 3
    bx lr


.word dva
.word tři

.arm nebo býval něco jako .code32 nebo .CODE 32 říká, že je to rameno kód není palec kód, který pro Cortex-M3 jste zvyklý muset použít.

.thumb podobně, býval .CODE 16 nebo možná, že ještě funguje, stejný problém je následující kód palec nezapne.

V případě, že etikety se používají, nejsou globální značky, které je třeba odbočit do jiných souborů, nebo nepřímo, pak zvyklý potřebovat .thumb_func. Aby však bylo možné na adresu pobočky k jednomu z těchto globálních značek, které mají být správně vypočítaný (lsbit je 1 pro palec a 0 bodů za rameno), který chcete označit jako palec nebo paže štítku a thumb_func dělá, jinak muset nastavit ten kousek před větvení přidáním většího množství kódu a značka není callable z C.


00000000 <_start>:
   0: eaffffff b 4 <jeden>

00000004 <jeden>:
   4: e2800001 přidat R0, R0, # 1
   8: e12fff1e bx lr

0000000c <dva>:
   c: 3002 přidává r0, # 2
   e: 4770 bx lr

00000010 <tři>:
  10: 3003 přidává R0, # 3
  12: 4770 bx lr
  14: 0000000c andeq r0, r0, ip
  18: 00000011 andeq r0, r0, r1, r0 LSL

Až do .thumb assembler je kód rameno, jak je požadováno.

Oba dva a tři štítky / funkce palec kód, jak je požadováno, ale dva etiketa má sudý adresu a tři má správný liché adresu.

Nejnovější CodeSourcery nástroje byly použity k sestavení, propojení, a výpisem výše uvedený vzorek.

Nyní pro Cortex-M3, kde je všechno palec (/ thumb2) thumb_func nemusí být tak důležité, může to prostě pracovat s přepínače příkazového řádku (velmi snadné dělat pokus zjistit). Je dobrým zvykem mít i když v případě, že odklon od palcem pouze procesor do normálního rameno / palec jádra.

Montéři obvykle chtěli přidat všechny tyto směrnice a jiné způsoby dělat věci vypadat / cítili jako jazyka vysoké úrovně. Já jen říkám, nemáte je používat, jsem přešel montéry za rameno a používat mnoho různých montéry z mnoha různých procesorů a raději méně je více přístup, to znamená zaměřit se na sestavě sebe a používat co nejméně nástrojů konkrétní položky jak je to možné. Jsem obvykle výjimka ne pravidlo i když, takže můžete pravděpodobně přijít na více často použitý směrnic při pohledu na to, co směrnic výstup kompilátor generuje (a ověřit s dokumentací).

unsigned int jeden (bez znaménka int x)
{
    návratu (x + 1);
}


    .arch armv5te
    .fpu softvfp
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 2
    .eabi_attribute 30, 2
    .eabi_attribute 18, 4
    .file "bob.c"
    .text
    .align 2
    .global jeden
    .type jednu,% funkci
jeden:
    .fnstart
.LFB0:
    @ args = 0, předstírat = 0, rám = 0
    @ Frame_needed = 0, = 0 uses_anonymous_args
    @ Odkaz registr uložit odstraněny.
    přidat R0, R0, # 1
    bx lr
    .fnend
    .size jeden,.-onu
    .ident "GCC: (prazdroj G ++ Lite 2.010,09-50) 4.5.1"
    .section .note.GNU-stack "",% progbits

Já použít .align při míchání rameno a palcem assembler nebo data s assembleru, měli byste očekávat, že assembler pro takovou platformu vědět něco tak zřejmé jako instrukce palec jsou na Poloviční slovo hranice a pokyny paží jsou zarovnány na hranice slov. Tyto nástroje nejsou vždy tak chytrý. zavodňování .aligns asi zvyklý bolet

.text je výchozí, takže je to trochu zbytečné, ale zvyklý ublížit. .text a .data jsou standardní atributy (nejsou specifické pro aktivaci) Pokud kompilace pro kombinaci ROM a RAM na svůj cíl, můžete starat (záleží na tom, co dělat s vaší linker skript), jinak .text bude pracovat pro všechno ,

.size zřejmě velikost funkce spuštění této směrnice. Assembler nemůže přijít na to samo o sobě, takže v případě, že velikost této funkce je důležitá pro váš kód, linker scénář, debugger, nakládce, ať pak to musí být v pořádku, jinak nemáte obtěžovat. Funkce je na vysoké úrovni koncepce stejně assembler doesnt opravdu funkce mnohem menší potřeba prokázat své velikosti. A C kompilátor jistě doesnt péči, je jen hledá štítku se rozdělit na a v případě rodiny ramene je to palec kód nebo kód rameno, který je rozvětvený do.

můžete najít direktivu .pool (existuje novější ekvivalent) užitečné, pokud jste líní se svými immediates (LDR RX = 0x12345678) na dlouhé úseky kódu. Zde opět nástroje nejsou vždy dost chytrý umístit tato data po bezpodmínečné větev, občas musíte jim říct. Říkám líný napůl vážně, je to bolestivé udělat štítek: .word co po celou dobu a já věřím, obě paže a GCC nástroje nechá za tímto zkratku, a tak jsem ji použít stejně jako kdokoliv jiný.

Také si všimněte, LLVM vysílá další .eabi_attribute nebo dva, který je podporován kód verze prazdroj je / mods do binutils, ale není podporováno (dosud snad) GNU binutils propuštěn. Dvě řešení, které pracují, měnit ASM tiskové funkce LLVM, aby ne psát eabi_attributes nebo alespoň napsat je s komentářem (@) nebo Získat binutils zdroj / mods z kódu prazdroj a stavět binutils tímto způsobem. Kód prazdroj má tendenci vést gnu (thumb2 podpora například), nebo snad backports nové funkce, takže předpokládám, že tyto LLVM attrubutes bude přítomen v hlavní řady binutils zanedlouho. I utrpěli žádné škodlivé účinky tím, ořezávání eabi_attributes pryč LLVM zkompilovaný kód.

Zde je LLVM výstup pro stejnou funkci výše, zřejmě se jedná o LLC, který jsem upravil na komentář mimo eabi_attributes.

    .syntax unifikovaný
@ .eabi_attribute 20, 1
@ .eabi_attribute 21, 1
@ .eabi_attribute 23, 3
@ .eabi_attribute 24, 1
@ .eabi_attribute 25, 1
@ .eabi_attribute 44, 1
    .file "bob.bc"
    .text
    .globl jeden
    .align 2
    .type jednu,% funkci
jedna jedna
@ BB # 0: @ entry%
    přidat R0, R0, # 1
    bx lr
.Ltmp0:
    .size jeden, .Ltmp0-onu

Elf formát souboru, je dobře zdokumentován a velmi snadno rozebrat, pokud chcete opravdu vidět, co elf zvláštní směrnice (pokud existují) dělají. Mnohé z těchto směrnic mají pomoci spojovací víc než cokoli jiného. .thumb_func, .text, .data např.

Odpovězeno 15/12/2010 v 00:44
zdroj uživatelem

hlasů
5

Narazil jsem na to, když se snaží přijít na to, proč ARM a Thumb převodní rozešel s nedávnými binutils (ověřeno s 2.21.53 (MacPorts), i 2,22 (Yagarto 4.7.1)).

Z mé zkušenosti, .thumb_funcdobře fungoval s dřívějšími binutils generovat správné převodní dýhy. Nicméně, u novějších vydáních .type *name*, %functionje zapotřebí směrnice pro zajištění řádného generaci dýha.

binutils mailing list pošta

Jsem příliš líný na to vykopat starší verzi binutils zkontrolovat, zda je .typesměrnice je v místě dostatečné .thumb_funcpro starší binutils. Myslím, že je v včetně obou směrnic v kódu nic špatného.

Upraveno: aktualizováno komentář k použití .thumb_funcv kódu, zřejmě to funguje u ARM-> Thumb spolupůsobením na vlajku palcem rutina generovat dýhy, ale vroubkovanou> ARM převodní selže, pokud .typedirektiva se používá k vlajce funkci ARM.

Odpovězeno 05/09/2012 v 04:52
zdroj uživatelem

hlasů
5

Úseky programu jsou úzce souvisí s formátem ELF, v němž většina systémů (Linux, BSD, ...) uložit svůj objekt a spustitelné soubory. Tento článek by vám měl poskytnout dobrou představu o tom, jak ELF práce, který vám pomůže pochopit, proč sekcí.

Jednoduše řečeno, profily umožňují organizovat svůj program do různých oblastí paměti, které mají různé vlastnosti, včetně adresy, povolení k provedení a psát, atd. V konečné fázi odkaz, linker používá konkrétní linker skript, který obvykle skupiny všech úsecích stejná pojmenovat dohromady (např všechny kód ze všech kompilace jednotek dohromady, ...) a přiřazuje jim konečnou adresu v paměti.

Vestavěných systémů je jejich použití je obzvláště zřejmá: za prvé, spouštěcí kód (obvykle obsažený v .textčásti) musí být načten v pevné adresy, aby mohly být provedeny. Potom, jen pro čtení dat lze rozdělit do vyhrazené části pouze pro čtení, která bude mapována do ROM prostoru zařízení. Poslední příklad: operační systémy mají inicializační funkce, které jsou volány jen jednou a pak se nikdy později použity, ztrácet drahocenný prostor v paměti. Jsou-li všechny tyto inicializační funkce seskupeny do části věnování zvané, řekněme, .initcodea je-li tento oddíl nastaven být poslední část programu, pak operační systém lze snadno získat zpět této paměti po spuštění dokončen snížením horní hranice ze své vlastní paměti. Linux například je známo používat tento trik, a GCC umožňuje umístit proměnnou nebo metodu do určitého úseku od postfixing ji__attribute__ ((section ("MYSECTION")))

.typea .sizejsou ve skutečnosti stále velmi nejasné pro mě taky. Vidím je jako pomocníci pro spojovací a nikdy viděl mimo kódu assembler generované.

.thumb_funczdá se být nutná pouze pro staré OABI rozhraní s cílem umožnit převodní s ramenem kód. Pokud používáte starou toolchain, pravděpodobně nebudete muset starat o to.

Odpovězeno 14/12/2010 v 08:06
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more