search for: readelf

Pinging this thread to see if anyone else has opinions or objections -- if not I plan to go ahead with stepping towards compatibility with readelf vs llvm-readelf in https://reviews.llvm.org/D54124 on Monday. On Tue, Nov 6, 2018 at 9:52 AM Jordan Rupprecht <rupprecht at google.com> wrote: > Hi James, > > I also wanted to work on this discrepancy, but I just sent a patch instead > of an RFC: https://reviews.llvm.org/D54124....

Hi all, A broad goal of many of the LLVM binary tools, such as llvm-objcopy and llvm-objdump is to provide an alternative to the GNU equivalent, and as such, these tools have been developed to be command-line compatible. One tool where this hasn’t been the case up to now is llvm-readobj (aka llvm-readelf). There was some discussion in https://reviews.llvm.org/D33872 about the purpose of llvm-readobj, so I’d like to ask the community's opinion. What is the purpose of llvm-readobj? Is it purely intended as an aid to testing? Should it be aiming to be GNU compatible, like most of the rest of the...

Hi all, llvm-readelf is an alias for llvm-readobj which aims for GNU compatibility and is likely the tool that most people migrating to the LLVM binutils will adopt instead of llvm-readobj. Because it is just an alias, it has inherited the functionality provided by llvm-readobj, including for non-ELF targets, with Mach...

My personal preference is that llvm-readelf only show the elf related options with -help and show all with -help-hidden. There is support for this in CommandLine.h, but I don't know how tricky it gets when we don't want them to be hidden for llvm-readobj. I haven't looked into this fully. For some reference, I have compiled how...

...[1] and the libelf wrapper from [2]. I also had to create a softlink /usr/lib/libelf.so.1 to get the script to run. Here is the command I used: "dom0cut.py -o xenImage -d ~/dumpcore1 --target=x -x ~/stuff/xen/xen-3.1-testing.hg/xen/xen-syms -telf". However, the script seemed to require eu-readelf to work. Therefore, I had to install elfutils (0.123-3). Then, I get the following errors: Traceback (most recent call la! st):   File "/usr/bin/dom0cut.py", line 8, in ?     import xendump.XenCore   File "/usr/lib/python2.4/site-packages/xendump/XenCore.py", line 7, in ?    ...

Add a simple test which uses scanelf or readelf to detect whether the supermin executable is really not executable. Kind of followup of commit c9f7a7998021e1cbe22a8ec325d43e2bdc3eff5a. --- tests/Makefile.am | 1 + tests/test-execstack.sh | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+) create mode 100755 tests/t...

...nerated labels. Now it no longer sees the label names and therefore puts them all into the final binary. I will demonstrate this on an example. If we compile the attached main.cpp file for ARM clang++ -c -o main.o -O0 -g --target=armv7l-linux-gnueabihf main.cpp and then look at the symbols readelf -s main.o there will be a number of similar entries (showing one entry only here for conciseness): Num: Value Size Type Bind Vis Ndx Name 7: 00000062 0 NOTYPE LOCAL DEFAULT 9 These are the .Linfo_string<index> symbols whose names are skipped due to r23664...

Hello all, The lld linker appears to generate extra ELF program headers and thus causes file sizes to be significantly larger than what would get with ld.gold or ld.bfd. # readelf -l test.bfd Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000...

...ject: Re: [llvm-dev] llvm-objdump print file offset Hi, This looks like a bug in llvm-objdump's output (I'd expect it to match GNU's). There are no options to print the other columns. Could you file a bug against llvm-objdump at https://bugs.llvm.org/, please? You could also use llvm-readelf to get equivalent output. For a simple object, it might look something like this: C:\Work\TOOLCHAIN-5886> \llvm\build\Debug\bin\llvm-readelf.exe -S C:\Work\TempWork\bar.o There are 12 section headers, starting at offset 0x208: Section Headers: [Nr] Name Type Address...

Hi All, I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf. If this is not the plan, will llvm-dwarfdump be a tool...

Hi all, I use llvm-clang with a MIPS target, and it seems that the backend generates wrong reloc info. I attach a very simple test case. * Compile test.c with 'clang -internal-as -g' * use mips-elf-objdump -S to get the generate assembly code (see test.lst) * use mips-elf-readelf -a to look for relocation info (see test.readelf) All relocations for static data are 0000 ?! I did not managed to locate the problem in the code, but I would be glad to help if someone can narrow the search area in the code base. Thanks for you help, -- Fred -------------- next part ------...

...ow how did the others move ? This is what I see with binutils/ld :- $cat 1.c #include "stdio_impl.h" static FILE *const dummy_file = 0; weak_alias(dummy_file, __stdin_used); weak_alias(dummy_file, __stdout_used); weak_alias(dummy_file, __stderr_used); $cat 2.c int __stdout_used = 10; $readelf -s 1.o | grep -E 'used|dummy_file' 6: 0000000000000000 8 OBJECT LOCAL DEFAULT 4 dummy_file 9: 0000000000000000 8 OBJECT WEAK DEFAULT 4 __stdin_used 10: 0000000000000000 8 OBJECT WEAK DEFAULT 4 __stdout_used 11: 0000000000000000 8 OBJECT WE...

...ng to make this the new style across all LLVM utilities? No. Only drop --long-option for GNU binutils replacements (people sometimes call them LLVM binary utilities): llvm-objcopy (D60439), llvm-ar, llvm-size, llvm-nm, etc. llvm-objdump (not sure what to do with mach-o specific dump options), llvm-readelf (not sure what to do with llvm-readobj) On Sat, Apr 20, 2019 at 2:13 AM Reid Kleckner <rnk at google.com> wrote: > Are you proposing to make this the new style across all LLVM utilities? > That seems needlessly disruptive. There are plenty of scripts that call > `opt` and `llc` dir...

Hello, $ objdump -h # displays info about all below sections.... Sections: Idx Name Size VMA LMA File off Algn While, $ llvm-objdump -h # only displays subset of info... Sections: Idx Name Size Address Type Using '--show-lma' could get VMA and LMA details. Can you suggest options to print 'File off' and

...com/D2762. > > If Android is using EHABI (I think it is), the default now is to > output full tables all the time, everywhere. This will change to be > the same as x86 soon. It does use EHABI, but at r201326: $ cat 1.cc int f() {} $ ./bin/clang++ -target arm-linux-androideabi 1.cc -c $ readelf -u 1.o 0x0 <_Z1fv>: 0x1 [cantunwind] $ ./bin/clang++ -target arm-linux-androideabi 1.cc -c -funwind-tables $ readelf -u 1.o 0x0 <_Z1fv>: 0x8000b0b0 Compact model 0 0x00 vsp = vsp + 4 0xb0 finish 0xb0 finish

...and less like a regular llvm utility. What do people think of the divergence? Further, can we make similar changes to other llvm binary utilities (their names give people the expectation), especially those with many short options such as llvm-objdump and llvm-readobj? llvm-readobj behaves like GNU readelf if you name it "llvm-readelf". (I don't suggest disallowing -long-option for utilities other than binutils) (Note, llvm-objcopy is a new member of the family and it uses tablegen based include/llvm/Option/Opton.h, instead of cl:: as other utilities do.) -- 宋方睿 -------------- next...

We have a similar option (-split-input-file) in `mlir-opt`: https://github.com/llvm/llvm-project/blob/master/mlir/test/Dialect/Affine/invalid.mlir With a single `RUN:` lit invocation the tool itself will loop over all the split sections in the file. This is convenient to test error cases where the tool would abort at the first error otherwise. I don't think we can easily achieve this with a

...gh sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us relocation entries in .rela.dyn section. Consider, for instance, the output of "readelf -r /bin/true": $ readelf -r /bin/true Relocation section '.rela.dyn' at offset 0xa80 contains 5 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000604c38 001800000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0 000000604de0 002...

...this for bitcode, object and archive files. > > * ranlib (Generates an index to the contents of an archive) -- There is an llvm-ranlib, but the docs at <http://llvm.org/docs/CommandGuide/llvm-ranlib.html> say that it only indexes bitcode files. Yep, needs object support. > > * readelf (Displays information from any ELF format object file) -- ???? llvm-readobj outputs the same format as readelf. > > * size (Lists the section sizes of an object or archive file) -- llvm-size does this for bitcode, object and archive files. > > * strings (Lists printable strings from f...

In regards to FreeBSD-SA-03:05.xdr, does anyone know which static binaries or tools under /bin or /sbin actually use that problem code? The recent XDR fixes the xdrmem_getlong_aligned(), xdrmem_putlong_aligned(), xdrmem_getlong_unaligned(), xdrmem_putlong_unaligned(), xdrmem_getbytes(), and/or xdrmem_putbytes() functions, but it is difficult to know what uses these (going backwards manually).