当气体ELF指令.TYPE,.thumb,.size和.section伪需要的? [英] When are GAS ELF the directives .type, .thumb, .size and .section needed?

查看:706
本文介绍了当气体ELF指令.TYPE,.thumb,.size和.section伪需要的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我工作的一个汇编程序为ARM Cortex-M3的微控制器(拇指2指令集),使用GNU作为。

I'm working on an assembly program for an ARM Cortex-M3 based microcontroller (Thumb 2 instruction set), using GNU as.

在一些示例code,我觉得像 .size .section伪指令和 .TYPE 我的理解是ELF指令。作为一个例子:

In some example code I find directives like .size, .section and .type which I understand are ELF directives. As an example:

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



.TYPE 指令说来设置符号的类型 - 以%的对象通常是(意味着数据?)或%功能。我不知道它使什么区别。它并不总是包括在内,所以我不能确定什么时候需要使用它。



The .type directive is said to set the type of a symbol - usually either to %object (meaning data?) or %function. I do not know what difference it makes. It is not always included, so I am unsure when it needs to be used.

也与此相关的是 .thumb_func 指令。从我读过它看起来像它的可能的是等价的:

Also related to this is the .thumb_func directive. From what I have read it seems like it might be equivalent of:

.thumb 
.type Symbol_Name, %function

或者是完全不同的东西?



.size 按说设置与符号相关联的大小。当这个是需要的,我不知道。这是在默认情况下计算的,但覆写投放此指令?如果是这样的 - 你什么时候想重写?

Or is it something completely different?



.size supposedly sets the size associated with a symbol. When this is needed, I have no idea. Is this calculated by default, but overrideable with this directive? If so - when would you want to override?



.section伪更容易找到的文档,我觉得我有什么的确实,但我还是有点不确定的用法。我的理解是,它不同的ELF节(文本为code,数据可写数据之间切换, BSS 未初始化的数据, rodata 他人常数,),并在需要时定义新的。我猜你会取决于你是否定义code,数据,未初始化的数据等,但为什么你会创建一个小节的函数,这些之间切换,如上面的例子吗?



.section is easier to find docs on, and I think I have a fair idea of what it does, but I am still a little bit unsure about the usage. The way I understand it, it switches between different ELF sections (text for code, data for writable data, bss for uninitialized data, rodata for constants, and others), and defines new ones when desired. I guess you would switch between these depending on whether you define code, data, uninitialized data, etc. But why would you create a subsection for a function, as in the example above?


任何这方面的帮助是AP preciated。如果你能找到教程的链接或文件,在更详细的解释 - preferably理解的新手 - 我将非常感激。


Any help with this is appreciated. If you can find links to tutorials or docs that explain this in greater detail - preferably understandable for a novice - I would be very grateful.

到目前为止,使用作为手册已经有一定的帮助 - 也许你可以比出来的我,用更多的知识。

So far, the Using as manual has been of some help - maybe you can get more out of it than me, with more knowledge.

推荐答案

我一直在编程的ARM / Thumb多年大量的汇编,并需要非常少的许多指令在那里的。

I have been programming arm/thumb for many years lots of assembler and have needed very few of the many directives out there.

作为另一个应答指出.thumb_func是非常重要的。

.thumb_func is quite important as pointed out by another responder.

例如:


.globl _start
_start:
    b   reset

reset:

.arm

.globl one
one:
    add r0,r0,#1
    bx lr

.thumb

.globl two
two:
    add r0,r0,#2
    bx lr

.thumb_func
.globl three
three:
    add r0,r0,#3
    bx lr


.word two
.word three

.ARM或曾经是类似。code32或。code 32告诉它这是手臂code不拇指code,这对于您的Cortex-M3的你不会需要使用。

.arm or used to be something like .code32 or .code 32 tells it this is arm code not thumb code, which for your cortex-m3 you wont need to use.

.thumb同样地,曾经是。code 16或者目前仍然可以工作,同样的协议作出以下code拇指武装不了。

.thumb likewise, used to be .code 16 or maybe that still works, same deal makes the following code thumb not arm.

如果您正在使用的标签是不是你需要从其他文件转移到或间接,那么不会需要.thumb_func全局标签。但为了一个分支来进行适当计算这些全球性的标签之一地址(所以LSb为拇指1和0的胳膊)你想将其标记为拇指或手臂标签和thumb_func这样做,否则你有分枝增加更多code之前设置该位和标签不调用从C

If the labels you are using are not global labels that you need to branch to from other files or indirectly, then wont need the .thumb_func. But in order for the address of a branch to one of these global labels to be computed properly (lsbit is a 1 for thumb and 0 for arm) you want to mark it as a thumb or arm label and the thumb_func does that, otherwise you have to set that bit before branching adding more code and the label is not callable from C.



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

00000004 <one>:
   4:   e2800001    add r0, r0, #1
   8:   e12fff1e    bx  lr

0000000c <two>:
   c:   3002        adds    r0, #2
   e:   4770        bx  lr

00000010 <three>:
  10:   3003        adds    r0, #3
  12:   4770        bx  lr
  14:   0000000c    andeq   r0, r0, ip
  18:   00000011    andeq   r0, r0, r1, lsl r0

截至.thumb汇编是根据需要手臂code。

Up to the .thumb the assembler is arm code as desired.

无论是两三个标签/功能是根据需要拇指code,但两个标签上有偶数地址和三个具有正确的奇数编号的地址。

Both the two and three labels/functions are thumb code as desired but the two label has an even numbered address and three has the proper odd numbered address.

最新codesourcery工具用于汇编,链接,并转储上面的示例。

The latest codesourcery tools were used to assemble, link, and dump the above sample.

现在的Cortex-M3的一切是拇指(/ thumb2)thumb_func可能不那么重要,它可能只是用命令行开关运行(很容易做到的一个实验来找出)。这是一个好习惯,虽然有万一你从一个只有拇指处理器搬走到正常的ARM / Thumb核心。

Now for the cortex-m3 where everything is thumb(/thumb2) thumb_func may not be as important, it may just work with command line switches (very easy to do an experiment to find out). It is a good habit to have though in case you move away from a thumb only processor to a normal arm/thumb core.

汇编一般都喜欢添加所有这些指令,使事情看起来/感觉更像是一个高级语言等方式。我只是说你没有使用它们,我换装配的手臂和使用许多不同的装配为许多不同的处理器和preFER的少即是多的方法,对大会本身,并使用尽可能少的工具,具体项目为意味着焦点可能。我平时例外而不是规则的,所以你也许可以通过看什么指令编译器输出产生弄清楚更常用的指令(和文档验证)。

Assemblers generally like to add all of these directive and other ways of making things look/feel more like a high level language. I am just saying you dont have to use them, I switched assemblers for arm and use many different assemblers for many different processors and prefer the less is more approach, meaning focus on the assembly itself and use as few tool specific items as possible. I am usually the exception not the rule though, so you can probably figure out the more often used directives by looking at what directives the compiler output generates (and verify with documentation).


unsigned int one ( unsigned int x )
{
    return(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 one
    .type   one, %function
one:
    .fnstart
.LFB0:
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
    add r0, r0, #1
    bx  lr
    .fnend
    .size   one, .-one
    .ident  "GCC: (Sourcery G++ Lite 2010.09-50) 4.5.1"
    .section    .note.GNU-stack,"",%progbits

我不使用.align伪与汇编混合ARM和Thumb汇编程序或数据时,你会期望汇编这样一个平台,要知道那样明显的Thumb指令都是半字上边界和ARM指令东西字边界对齐。这些工具并不总是那么聪明。大约不会伤害洒.aligns

I do use the .align when mixing arm and thumb assembler or data in with assembler, you would expect the assembler for such a platform to know something as obvious as thumb instructions are on halfword boundaries and arm instructions are aligned on word boundaries. The tools are not always that smart. sprinkling .aligns about wont hurt

的.text是默认的,这样是有点多余,但不会伤害。 .text段和。数据是标准的属性(不特定于ARM),如果编译的ROM和RAM上你的目标,你可能关心的组合(取决于你与你的链接脚本做什么),否则会的.text一切工作。

.text is the default so that is a bit redundant, but wont hurt. .text and .data are standard attributes (not specific to arm) if you are compiling for a combination of rom and ram on your target you may care (depends on what you do with your linker script), otherwise .text will work for everything.

.size显然的函数的大小开始该指令。汇编器不能算出这个对自己,因此,如果该功能的大小为您的code,链接脚本,调试器,装载机,无论那么这必须是正确的重要的,否则你不必理会。函数是一个高层次的概念反正汇编并没有真正具备的功能要少得多,需要申报的大小。和C编译器肯定不关心,只想找一个标签分支到,并在ARM系列的情况下,它的拇指code或手臂code,正在支到。

.size apparently the size of the function start to that directive. The assembler cannot figure this out on its own, so if the size of this function is important for your code, linker script, debugger, loader, whatever then this needs to be right, otherwise you dont have to bother. A function is a high level concept anyway assembler doesnt really have functions much less a need to declare their size. And the C compiler certainly doesnt care, it is only looking for a label to branch to and in the case of the arm family is it thumb code or arm code that is being branched to.

您可能会发现.pool指令,如果你是懒惰的你在code的很长一段立即数(LDR RX = 0x12345678的)(有一个较新的等价物)是有用的。这里再次工具并不总是足够聪明无条件转移后,把这个数据,你有时不得不告诉他们。我说懒半认真,很是痛苦做标签:.word的事情所有的时间,我相信无论是手臂和GCC工具,允许该快捷方式,所以我用它,就像其他任何人

you may find the .pool directive (there is a newer equivalent) useful if you are lazy with your immediates (ldr rx,=0x12345678) on long stretches of code. Here again the tools are not always smart enough to place this data after an unconditional branch, you sometimes have tell them. I say lazy half seriously, it is painful to do the label: .word thing all the time and I believe both the arm and gcc tools allowed for that shortcut, so I use it as much as anyone else.

另外请注意LLVM输出由code的Sourcery的版本中支持额外的.eabi_attribute两/ MODS的binutils的,但不支持(或许还)由GNU binutils的释放。两个解决方案的工作,修改LLVM的ASM打印功能不写eabi_attributes或者至少它们与评论(@)写或获得binutils的源/从code的Sourcery MODS和建立的binutils的方式。 code的Sourcery往往导致GNU(例如thumb2支持)或者backports中的新功能,所以我想这些LLVM attrubutes将在主线的binutils present不久。我已经通过调整eabi_attributes关闭LLVM编译code的没有受到不良影响。

Also note llvm outputs an additional .eabi_attribute or two that is supported by code sourcery's version/mods to binutils but not supported (perhaps yet) by the gnu released binutils. Two solutions that work, modify llvm's asm print function to not write the eabi_attributes or at least write them with a comment (@), or get the binutils source/mods from code sourcery and build binutils that way. code sourcery tends to lead gnu (thumb2 support for example) or perhaps backports new features, so I assume these llvm attrubutes will be present in the mainline binutils before long. I have suffered no ill effects by trimming the eabi_attributes off of the llvm compiled code.

下面是上述相同功能的LLVM输出,显然这是我修改注释掉eabi_attributes的有限责任公司。

Here is the llvm output for the same function above, apparently this is the llc that I modified to comment out the eabi_attributes.


    .syntax unified
@   .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  one
    .align  2
    .type   one,%function
one:                                    @ @one
@ BB#0:                                 @ %entry
    add r0, r0, #1
    bx  lr
.Ltmp0:
    .size   one, .Ltmp0-one

ELF文件格式是有据可查的,很容易解析,如果你想真正看到什么精灵具体指示(如有)正在做的。许多这些指令是帮助链接比什么都重要。 .thumb_func,的.text段,.data例子。

The elf file format is well documented and very easy to parse if you want to really see what the elf specific directives (if any) are doing. Many of these directives are to help the linker more than anything. .thumb_func, .text, .data for example.

这篇关于当气体ELF指令.TYPE,.thumb,.size和.section伪需要的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆