search for: stt_func

Jim, I didn’t understood why foo is not marked with type 'FUNC'. At least as per elf standard symbol foo should be marked as 'FUNC' STT_FUNC: The symbol is associated with a function or other executable code. Regards, Ashutosh -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jim Grosbach Sent: Friday, July 03, 2015 3:31 AM To: Soumitra Chatterjee Cc: llvmdev at cs....

...utosh <Ashutosh.Nema at amd.com> wrote: >> Jim, I didn’t understood why foo is not marked with type 'FUNC'. > > Just convention, as far as I can tell (certainly GNU as does the same > thing for undefined symbols). > > The ARM ELF ABI says that either STT_NOTYPE or STT_FUNC would be > acceptable on that platform, the x86_64 ABI seems to be silent on the > issue. > >> At least as per elf standard symbol foo should be marked as 'FUNC' >> STT_FUNC: The symbol is associated with a function or other executable code. > > For whatever re...

I noticed that LLD doesn’t preserve the symbol type for a defsym directive. For example: $ cat f.c void f() {} $ clang -c f.c $ ld.lld -shared --defsym=g=f f.o $ objdump -T a.out DYNAMIC SYMBOL TABLE: 00000000000012a0 g DF .text 0000000000000006 f 00000000000012a0 g D .text 0000000000000000 g f is marked as a function symbol, but g is not. I recognize this is hard to do in the general

...the addresses for tBL/tBLX are not calculated right. With that attached patch, we can compile and run some (not all) Android NDK samples without problem. The attached initial patch 1. sets bit 0 of the function address of thumb function in .symtab ("T is 1 if the target symbol S has type STT_FUNC and the symbol addresses a Thumb instruction ;it is 0 otherwise." from "ELF for the ARM Architecture" 4.7.1.2) 2. fixes target address tBL and tBLX 3. sets relocation type of tBL/tBLX to R_ARM_THM_CALL (4.7.1.6) 4. adds some attributes to attribute section when cpu is &quo...

...lvm/Object/ELF.h (working copy) @@ -1000,7 +1000,7 @@ switch (symb->getType()) { case ELF::STT_SECTION: - Result = Section ? Section->sh_addr : UnknownAddressOrSize; + Result = Section ? Section->sh_offset : UnknownAddressOrSize; return object_error::success; case ELF::STT_FUNC: case ELF::STT_OBJECT: -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130118/506f6f0a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: section...

...t calculated right. > > With that attached patch, we can compile and run some (not all) Android > NDK samples without problem. > > The attached initial patch > 1. sets bit 0 of the function address of thumb function in .symtab > ("T is 1 if the target symbol S has type STT_FUNC and the > symbol addresses a Thumb instruction ;it is 0 otherwise." > from "ELF for the ARM Architecture" 4.7.1.2) > > 2. fixes target address tBL and tBLX > 3. sets relocation type of tBL/tBLX to R_ARM_THM_CALL > (4.7.1.6) > 4. adds some attributes to at...

Hi Nowadays I am using LLVM to do ARM binary analysis. I was wondering is llvm available to provide some debugging information on the mode of ARM. For example, llvm-dwarfdump could dump some instructions information for debugging. Is it able to know the mode for each instruction? Or we may write some llvm pass to help us to know the instruction mode? Any suggestions are welcomed. Many Thanks

...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; + } + + uint64_t Address; + getSymbolOffset(Symb, Address); + + if (sym->getType() == ELF::STT_FUNC Again, this will only work for functions. Symbols without this type can also be in a section. + && Address >= sec->sh_addr + && Address < (sec->sh_addr + sec->sh_size)) + Result = true; + return object_error::success; } template<support::endianness...

...+++ b/include/llvm/MC/MCDirectives.h @@ -17,32 +17,32 @@ namespace llvm { enum MCSymbolAttr { - MCSA_Invalid = 0, /// Not a valid directive. + MCSA_Invalid = 0, ///< Not a valid directive. // Various directives in alphabetical order. - MCSA_ELF_TypeFunction, /// .type _foo, STT_FUNC # aka @function - MCSA_ELF_TypeIndFunction, /// .type _foo, STT_GNU_IFUNC - MCSA_ELF_TypeObject, /// .type _foo, STT_OBJECT # aka @object - MCSA_ELF_TypeTLS, /// .type _foo, STT_TLS # aka @tls_object - MCSA_ELF_TypeCommon, /// .type _foo, STT_COMMON # aka @common - MCS...

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

...start of OS-specific */ +#define STB_HIOS 12 /* end of OS-specific */ +#define STB_LOPROC 13 /* start of processor-specific */ +#define STB_HIPROC 15 /* end of processor-specific */ + +#define STT_NOTYPE 0 /* symbol type is unspecified */ +#define STT_OBJECT 1 /* symbol is a data object */ +#define STT_FUNC 2 /* symbol is a code object */ +#define STT_SECTION 3 /* symbol associated with a section */ +#define STT_FILE 4 /* symbol's name is file name */ +#define STT_COMMON 5 /* symbol is a common data object */ +#define STT_TLS 6 /* symbol is thread-local data object*/ +#define STT_NUM 7 /* number...

...not calculated right. > > With that attached patch, we can compile and run some (not all) Android > NDK samples without problem. > > The attached initial patch > 1. sets bit 0 of the function address of thumb function in .symtab >   ("T is 1 if the target symbol S has type STT_FUNC and the >   symbol addresses a Thumb instruction ;it is 0 otherwise." >   from "ELF for the ARM Architecture" 4.7.1.2) > > 2. fixes target address tBL and tBLX > 3. sets relocation type of tBL/tBLX to R_ARM_THM_CALL >    (4.7.1.6) > 4. adds some attributes to att...

...HT_PROGBITS Flags: [ SHF_ALLOC, SHF_WRITE ] - Name: .dynamic Type: SHT_DYNAMIC Entries: - Tag: DT_SONAME Value: libsomething.so - Tag: DT_SYMTAB Value: .dynsym - Tag: DT_SYMENT Value: 0x18 DynamicSymbols: Global: - Name: foo Type: STT_FUNC Section: .data - Name: bar Type: STT_OBJECT Section: .data The final section is of type SHT_DYNAMIC, and the "Entries" key illustrates the proposed addition. Walking through the three dynamic entries, 1. DT_SONAME: The value of this entry is a string that will be...

Hi, I am a bit stumped on the following case, and hopefully missing something very basic. Can someone please help me understand why the following is allowed to link correctly? $ cat -n main.c 1 extern void foo(); 2 3 int main() { foo(); } $ cat -n def.c 1 int foo = 99; $ clang main.c def.c ; echo $? 0 I guess the answer depends on why is 'main.c::foo' not

...space. The address of a "routine" is the address of its function descriptor since you need both the code address and the GP value to call the routine. (Yes, our linker does something slightly non-standard with the DIR32LSB/DIR64LSB relocations by treating them as FPTR32LSB/FPTR64LSB for STT_FUNCs so you can actually never obtain the code address via linker relocation). The idea to make this all work on x86-64 is to use the address of a routine's PLT as its "address" in all cases. By putting the PLT in 32-bit address space, some ancient BASIC or Fortran program can continue...

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

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