search for: stt_funcs

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

Someone in my team pointed to an open bug about this in gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514 Would this be applicable to Clang as well? Thanks, Soumitra On 03-Jul-2015 10:53 AM, Tim Northover wrote: > On 2 July 2015 at 21:51, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: >> Jim, I didn’t understood why foo is not marked with type 'FUNC'. > >

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

Hi, We are trying to use clang as a drop-in replacement for the gcc come with Android NDK. I found that MC/ELF doesn't not handle Thumb functions properly, e.g., bit 0 of the function name in the .symtab is not set to 1, and some thumb instructions are not generated correctly, e.g., the addresses for tBL/tBLX are not calculated right. With that attached patch, we can compile and run some

While working on some other changes I came across a problem where ELFObjectFile::getSymbolFileOffset was returning a different value than I expected in the case where the symbol in question was a section. Looking at the code, it seems obviously wrong, but I didn't want to just commit my change without at least asking if anyone knew of a good reason for the current behavior. I know there

Hi Koan, In general, this looks OK to me. Please split the patch into separate pieces, one for each issue you're addressing, though. From your description, it sounds like this should be 4 patches. That way we have a cleaner revision history in svn. -Jim On May 12, 2011, at 10:42 PM, Koan-Sin Tan wrote: > Hi, > > We are trying to use clang as a drop-in replacement for the gcc come

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

On Wed, Oct 12, 2011 at 3:17 AM, Songmao <smtian at ingenic.cn> wrote: > 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 > @@ -747,12 +747,28 @@ error_code

Some doxygen annotations are attached to the wrong entry, which can be misleading. This patch fixes the mistake everywhere I could find it. --- include/llvm/InstrTypes.h | 54 ++++++++++++++++++++-------------------- include/llvm/MC/MCDirectives.h | 42 +++++++++++++++--------------- include/llvm/Pass.h | 10 +++--- 3 files changed, 53 insertions(+), 53 deletions(-) diff

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

This is a patch that I've had kicking around that I never sent in. With it applied I can compile the module programs from module-init-tools: diff -uNr klibc-0.178/include/sys/elf32.h klibc-0.178-fogo/include/sys/elf32.h --- klibc-0.178/include/sys/elf32.h 2004-01-30 14:40:51.000000000 -0700 +++ klibc-0.178-fogo/include/sys/elf32.h 2004-09-20 09:15:58.000000000 -0600 @@ -7,6 +7,10 @@

splited patches and test cases mc-elf-thumbfunction-bit.diff: for 1 mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. mc-elf-cpu-xscale-attributes.diff: for 4. elf-thumbfunc.s: test case for 1 elf-thumbfunc-reloc.ll: test case for 2 and 3 elf-xscale-attribute.ll: test case for 4 On Fri, May 13, 2011 at 1:42 PM, Koan-Sin Tan <koansin.tan

The goal of this proposal is to introduce a new type of YAML section for yaml2obj that allows the population of ELF .dynamic entries via a list of tag and value pairs. These entries are interpreted (and potentially validated) before being written to the .dynamic section. The simplest way to satisfy this requirement is for all dynamic entry values to be numeric values. Unfortunately, this

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

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