search for: st_value

2012/1/23 Bendersky, Eli <eli.bendersky at intel.com>: > Hi, > > I would like to examine the implications you mention in more detail. > Thank you! > (1) Symbol address > According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, > st_value is an offset from the beginning of the section that st_shndx identifies." (*) > > Therefore, when queried about a symbol's address what would the right answer be? In ELFObj...

Hi, I would like to examine the implications you mention in more detail. (1) Symbol address According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's address what would the right answer be? In ELFObjectFile::getSy...

Thanks, Shankar. I needed to override all the places where st_value had been used, and it worked. But there another problem appeared: after correcting all atoms, I cannot distinguish between ARM and Thumb symbols in the further stages when fixing up relocations. I used to check targetVAddress (in terms of the relocation handler) since it contained 1 in the least...

Hi all, I'm using the MC framework for a project, and while updating to latest trunk (r148672) encountered the following issue: It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have been changed to add the symbol's offset to the offset of the containing section? This has the following implications: To get the /actual/ fileoffset, I now need to do: Symbol.getFileOffset()

...etadata information about a symbol in special absolute symbols, "__sym_attr_metadata.<int>", that the linker can recognize when scanning the symbol table for an incoming object file. In an ELF symbol table entry: typedef struct { Elf32_Word st_name; Elf32_Addr st_value; Elf32_Word st_size; unsigned char st_info; unsigned char st_other; Elf32_Half st_shndx; } Elf32_Sym; typedef struct { Elf64_Word st_name; unsigned char st_info; unsigned char st_other; Elf64_Half st_shndx; Elf64_Ad...

...finedAtom<ELFT> *createDefinedAtomAndAssignRelocations( > StringRef symbolName, StringRef sectionName, const Elf_Sym *symbol, > const Elf_Shdr *section, ArrayRef<uint8_t> content) { > @@ -380,6 +534,11 @@ private: > (ri->r_offset < symbol->st_value + content.size())) { > auto *ERef = new (_readerStorage) > ELFReference<ELFT>(ri, ri->r_offset - symbol->st_value, nullptr); > + // Read the addend from the section contents > + // TODO : We should move the way lld reads relocation...

...ymbol in special absolute symbols, “__sym_attr_metadata.<int>”, that the linker can recognize when scanning the symbol table for an incoming object file. In an ELF symbol table entry: > > > > typedef struct { > > Elf32_Word st_name; > > Elf32_Addr st_value; > > Elf32_Word st_size; > > unsigned char st_info; > > unsigned char st_other; > > Elf32_Half st_shndx; > > } Elf32_Sym; > > > > typedef struct { > > Elf64_Word st_name; > > unsigned char...

...s, “__sym_attr_metadata.<int>”, that the linker can recognize when scanning the symbol table for an incoming object file. In an ELF symbol table entry: > > > > typedef struct { > > Elf32_Word st_name; > > Elf32_Addr st_value; > > Elf32_Word st_size; > > unsigned char st_info; > > unsigned char st_other; > > Elf32_Half st_shndx; > > } Elf32_Sym; > > > > typedef struct { > &gt...

...; "globals are points" invariant is nice, but making LLVM IR more accurately > model object file formats is also good. I would say that requiring a pointer type, specially when there is only one pointer type in the future, is closer to what the object format is. In ELF you will get an st_value regardless of it being absolute of a position in the file. It doesn't really make sense to have a type that is not at least pointer sized. Cheers, Rafael

...g the symbol table for an incoming object file. In an ELF symbol table entry: > > > > > > > > > > > > typedef struct { > > > > > > Elf32_Word st_name; > > > > > > Elf32_Addr st_value; > > > > > > Elf32_Word st_size; > > > > > > unsigned char st_info; > > > > > > unsigned char st_other; > > > > > > Elf32_Half st_shndx; > > > &...

On Tue, Oct 25, 2016 at 6:52 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > So, to summarise the overall consensus on this thread: > - We should introduce a GlobalConstant class which supports definitions > and declarations > - It should derive from GlobalValue > - No type changes for GlobalValue (i.e. still required to be pointer type) > - To communicate the range

...4.6.5.1 of the ELF for ARM document? Yes, they are. > And what to put in the alignment field? I see GCC outputting 1, 3, 4, but I don't see a > description of that field in the doc. I don't think individual symbols have an alignment in ELF (except COMMON ones, which repurpose the st_value field -- not the case here). If the 1, 3, 4 are coming from the last column of the dumps you produced below, they're referring to the section the symbol is relative to (st_shndx in the documentation). Cheers. Tim.

..., "init_per_cpu_", 13); } +/* + * Check if the 32-bit relocation is within the xenpvh 32-bit code. + * If so, ignores it. + */ +static int is_in_xenpvh_assembly(ElfW(Addr) offset) +{ + ElfW(Sym) *sym = sym_lookup("pvh_start_xen"); + return sym && (offset >= sym->st_value) && + (offset < (sym->st_value + sym->st_size)); +} static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, const char *symname) @@ -895,8 +905,12 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, * the relocations are pro...

...g the symbol table for an incoming object file. In an ELF symbol table entry: > > > > > > > > > > > > typedef struct { > > > > > > Elf32_Word st_name; > > > > > > Elf32_Addr st_value; > > > > > > Elf32_Word st_size; > > > > > > unsigned char st_info; > > > > > > unsigned char st_other; > > > > > > Elf32_Half st_shndx; > > > &...

...of STT_FILE. The goal is not just to pass through ELF-isms. The goal is to define a really good model and translate each object format into that model. A web search for STT_FILE gives: > In this case for it may be an ELF'ism, when st_info == STB_LOCAL | STT_FILE st_shndx == SHN_ABS Then st_value will probably be zero and this symbol's name should match the name of the originating source file. Currently there is only one qualifying characteristic a symbol must have in order to be converted into an absolute atom, st_shndx == SHN_ABS. The problem is that symbols with this attribute can...

...ntry: >> > > > >> > > > >> > > > >> > > > typedef struct { >> > > > >> > > > Elf32_Word st_name; >> > > > >> > > > Elf32_Addr st_value; >> > > > >> > > > Elf32_Word st_size; >> > > > >> > > > unsigned char st_info; >> > > > >> > > > unsigned char st_other; >> > > > >>...

...o '1'. > so how these logic can be implemented while still adapt to the structure of > the code? > > Songmao For the first patch. The code is only valid for executable files, not relocatable files. st_shndx should be used to determine if the symbol is in the given section. Also st_value can hold the offset into st_shndx, not the actual address. Also it doesn't handle non-function symbols. For the second patch. Could you explain what exactly you are trying to fix? I see some stuff that I know is wrong, but it would help if I knew the intent. As for what I do know. * The error...

...e. In an > ELF symbol table entry: > > > > > > > > > > > > > > > > typedef struct { > > > > > > > > Elf32_Word st_name; > > > > > > > > Elf32_Addr st_value; > > > > > > > > Elf32_Word st_size; > > > > > > > > unsigned char st_info; > > > > > > > > unsigned char st_other; > > > > > > > > Elf32...

...oal is to define a really good model and > translate each object format into that model. A web search for STT_FILE > gives: > >> > > In this case for it may be an ELF'ism, when > > st_info == STB_LOCAL | STT_FILE > > st_shndx == SHN_ABS > > > > Then st_value will probably be zero and this symbol's name should match > > the name of the originating source file. > The lld::File class has a method translationUnitSource() that (if > available) returns the path to the source file that created this object > file. If this matches the semant...

Hi, I am new to llvm, not familiar with c++, after some use with llvm-objdump, and finding the broken output, I try to debug and fix the code so it can become usable. Please help review the patch, so that they can be merged. And there's still two major problem I have found about arm disassembler: 1. arm instruction decoder cannot recognise bx series instructions. 2. As gcc will