search for: st_shndx

...e more about the semantics 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 symbo...

...entry, when in thumb code, the lowest bit of the symbol value will be > set to '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 w...

...ot 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. > The lld::File class has a method translationUnitSource() that (if > available) returns the path to the source file that created this...

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

...antics 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. 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 ma...

...an 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_Addr st_value; Elf64_Xword st_size; } Elf64_Sym; The st_size and st_value fields could be used to represent attri...

...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. > The lld::File class has a method translationUnitSource() that (if available) returns the path to the source file that created this objec...

...d 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.

...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_Addr st_value; > > Elf64_Xword...

...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 ELFObjectFile::getSymbolAddress, previously, it was simply symb->st_value (which is the relative offset to the section). Now, Section->sh_addr is added to reflect the actual...

...def 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; > &gt...

...DataRefImpl Symb, bool &Result) const { - // FIXME: Unimplemented. + Result = false; + const Elf_Sym *sym = getSymbol(Symb); + const Elf_Shdr *sec = reinterpret_cast<const Elf_Shdr *>(Sec.p); + + if (getSection(sym->st_shndx) != sec) { This version of getSection will not handle extended section indices properly. Use the version that takes a const Elf_Sym*. This also fails when there is no section table, which is not required for executables or shared libraries. + Result = false; + return object_error::success;...

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

...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::getSymbolAddress, previously, it was simply symb->st_value (which is the relative offset to the section). Now, Section->sh_addr is added to reflect the actual address...

This adds [f]getc() and fgets() for parsing config files. Probably hard to avoid. Still trying to decide if I actually want to add system() or not. -hpa

On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: > > I think that absolute atoms will need something similar to, "contentType" added. > > SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

...+ + /* + * If a _GLOBAL_OFFSET_TABLE_ symbol exists, make it absolute for + * modules to correctly reference it. Similar to s390 implementation. + */ + strings = (void *) ehdr + sechdrs[symtab->sh_link].sh_offset; + for (i = 0; i < symtab->sh_size/sizeof(Elf_Sym); i++) { + if (syms[i].st_shndx != SHN_UNDEF) + continue; + name = strings + syms[i].st_name; + if (!strcmp(name, "_GLOBAL_OFFSET_TABLE_")) { + syms[i].st_shndx = SHN_ABS; + break; + } + } + return 0; +} +#endif + void *module_alloc(unsigned long size) { void *p; @@ -190,16 +358,20 @@ int apply_relocate_add...

I think that absolute atoms will need something similar to, "contentType" added. SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a contentType method to AbsoluteAtom and sprinkled changes around to