Summary:
This patch displays a hexadecimal section value (Elf_Shdr::sh_type) or section-relative offset when printing unknown sections.
Here is a subset of the output (ignoring the fields following "Type" when dumping an ELF's GNU `--section-headers` table).
Section Headers:
```
[Nr] Name Type
[16] android_rel LOOS+0x1
[17] android_rela LOOS+0x2
[27] unknown 0x1000: <unknown>
[28] loos LOOS+0
[30] hios VERSYM
[31] loproc LOPROC+0
[33] hiproc LOPROC+0xFFFFFFF
[34] louser LOUSER+0
[36] hiuser LOUSER+0x7FFFFFFF
```
As a comparison, the previous output looked something like the above, but with a blank "Type" field:
```
[Nr] Name Type
[27] unknown
[28] loos
[30] hios VERSYM
[31] loproc
[33] hiproc
[34] louser
[36] hiuser
```
This fixes PR40773
Reviewers: jhenderson, rupprecht, Bigcheese
Reviewed By: jhenderson, rupprecht, Bigcheese
Subscribers: MaskRay, Bigcheese, srhines, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58701
llvm-svn: 355014
initializes a local auto variable or is assigned to a local auto
variable that is declared in the scope that introduced the block
literal.
rdar://problem/13289333
https://reviews.llvm.org/D58514
llvm-svn: 355012
The original intent was to enable this test for Windows; however, that
initial patch broke one of the build-bots. I temporarily disabled this
test on Windows until that issue was resolved. It was resolved in my
previous patch (cfd1d9742ee2d1b8dd6b7), and now I am re-enabling this
test.
llvm-svn: 355011
Frameworks filesystem representations:
UIKit.framework/Headers/%header%
Framework import format:
#import <UIKit/%header%>
Thus the completion code must map the input format of <UIKit/> to
the path of UIKit.framework/Headers as well as strip the
".framework" suffix when auto-completing the framework name.
llvm-svn: 355008
Ideally this is a NFCI, used single quotes in most cases. Hopefully
this will make the Windows bot happy.
I've marked this unsupported on windows, until I get my windows box
setup with this patch to test. I'll remove that constraint after I'm
confident this will pass on windows. I just want to silence the
buildbots for now.
llvm-svn: 355007
This patch adds testing of areas of the code that are not fully tested,
in particular dynamic table printing, ELF type printing, handling of
edge cases where things are missing/empty (relocations/program header
tables/section header table), and the --string-dump switch.
Reviewed by: grimar, higuoxing, rupprecht
Differential Revision: https://reviews.llvm.org/D58677
llvm-svn: 355003
Debugging issues with instrumentation capture and replay can be
particularly tricky, especially because part of the process takes places
even before the debugger is initialized. This patch adds more logging
capabilities to these classes, hidden behind a macro define.
Differential revision: https://reviews.llvm.org/D58566
llvm-svn: 355002
Summary:
Before:
```
Dynamic Section:
NEEDED libpthread.so.0
...
NEEDED ld-linux-x86-64.so.2
RPATH 0x00000000001c2e61
```
After:
```
Dynamic Section:
NEEDED libpthread.so.0
...
NEEDED ld-linux-x86-64.so.2
RPATH $ORIGIN/../lib
```
Only a small problem here, I have no idea on choosing test case. I see there's a test
file(test/tools/llvm-objdump/private-headers-dynamic-section.test). But it has no DT_RPATH and DT_RUNPATH tags. Shall I replace the ELF file in the
Inputs dir by a new one?
Reviewers: jhenderson, grimar
Reviewed By: jhenderson
Subscribers: srhines, rupprecht, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58707
llvm-svn: 355001
Summary:
Even if the content cache has a directory and filename, it may be a virtual file.
The old code returned with error in this case, but it is worth to try to handle
the file as it were a memory buffer.
Reviewers: a.sidorin, shafik, martong, a_sidorin
Reviewed By: shafik
Subscribers: efriedma, rnkovacs, cfe-commits, dkrupp, martong, Szelethus, gamesh411
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57590
llvm-svn: 355000
Summary:
This CL adds a standalone vector class that will be used by the scoped
strings when they land. We reimplement our own vector class because we
can't use the std library one.
It's mostly borrowed from the current sanitizer_common one, with LLVM
code style changes.
Additionnally a casing change in a function name that slipped through
the previous review (the function isn't used yet).
Reviewers: vitalybuka, eugenis, flowerhack, dmmoore415, mcgrathr, morehouse
Reviewed By: vitalybuka
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58689
llvm-svn: 354999
Summary:
This patch attempts to replicate GNU c++-filt behavior when splitting stdin input for demangling.
Previously, cxx-filt would split input only on spaces. Each delimited item is then demangled.
From what I have tested, GNU c++filt also splits input on any character that does not make
up the mangled name (notably commas, but also a large set of non-alphanumeric characters).
This patch splits stdin input on any character that does not belong to the Itanium mangling
format (since Itanium is currently the only supported format in llvm-cxxfilt).
This is an update to PR39990
Reviewers: jhenderson, tejohnson, compnerd
Reviewed By: compnerd
Subscribers: erik.pilkington, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58416
llvm-svn: 354998
Summary:
The text was written mostly by Sam McCall, screenshots are mostly made
by me.
Reviewers: ilya-biryukov
Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58710
llvm-svn: 354992
As discussed elsewhere: LLVM uses cpp as its C++ source extension; the
sanitizers should too. This updates files in hwasan.
Patch generated by
for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done
followed by
for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done
CMakeLists.txt updated manually.
Differential Revision: https://reviews.llvm.org/D58620
llvm-svn: 354989
When using full LTO it is possible that template function definition DIE
is bound to one compilation unit and it's declaration to another. We should
add function declaration attributes on behalf of its owner CU otherwise
we may end up with malformed file identifier in function declaration
DW_AT_decl_file attribute.
Differential revision: https://reviews.llvm.org/D58538
llvm-svn: 354978
It turns out these tests actually succeed, if one has a clang with
address sanitizer support enabled (i.e., has enabled the compiler-rt
project). I guess none of the linux lldb devs have done that until now.
llvm-svn: 354976
Summary:
Swig is perfectly capable of inserting blocks of python code into its
output (and we use those fascilities already), so there's no need for
this to be done in a post-process step.
lldb_iter is a general-purpose utility used from many classes, so I add
it to the main swig file. The other two blocks are tied to a specific
class, so I add it to the interface file of that class.
Reviewers: zturner, jingham, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58350
llvm-svn: 354975
That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
"wrong line number info for obj file compiled with -ffunction-sections"
bug. The problem happened with only .o files. If object file contains
several .text sections then line number information showed incorrectly.
The reason for this is that DwarfLineTable could not detect section which
corresponds to specified address(because address is the local to the
section). And as the result it could not select proper sequence in the
line table. The fix is to pass SectionIndex with the address. So that it
would be possible to differentiate addresses from various sections. With
this fix llvm-objdump shows correct line numbers for disassembled code.
Differential review: https://reviews.llvm.org/D58194
llvm-svn: 354972
Summary:
Suppose `clangd::` is unresolved in the following example. Currently,
we simply use "clangd::" as the query scope. We can do better by combining with
accessible scopes in the context. The query scopes can be `{clangd::, clang::clangd::}`.
```
namespace clang { clangd::^ }
```
Reviewers: ilya-biryukov, sammccall, hokein, kadircet
Reviewed By: kadircet
Subscribers: MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58448
llvm-svn: 354963
llvm-readobj's error messages were broken for bad archive members. This
patch fixes them, and also adds testing for archive and thin archive
handling within llvm-readobj.
Reviewed by: rupprecht, grimar, higuoxing
Differential Revision: https://reviews.llvm.org/D58681
llvm-svn: 354960
This patch removes the precompiled binary from inputs,
replacing it with a YAML. And teaches LLD to report a
section name in case of such error.
Differential revision: https://reviews.llvm.org/D58670
llvm-svn: 354959
Currently, the LLVM will print an error like
Unsupported relocation: try to compile with -O2 or above,
or check your static variable usage
if user defines more than one static variables in a single
ELF section (e.g., .bss or .data).
There is ongoing effort to support static and global
variables in libbpf and kernel. This patch removed the
assertion so user programs with static variables won't
fail compilation.
The static variable in-section offset is written to
the "imm" field of the corresponding to-be-relocated
bpf instruction. Below is an example to show how the
application (e.g., libbpf) can relate variable to relocations.
-bash-4.4$ cat g1.c
static volatile long a = 2;
static volatile int b = 3;
int test() { return a + b; }
-bash-4.4$ clang -target bpf -O2 -c g1.c
-bash-4.4$ llvm-readelf -r g1.o
Relocation section '.rel.text' at offset 0x158 contains 2 entries:
Offset Info Type Symbol's Value Symbol's Name
0000000000000000 0000000400000001 R_BPF_64_64 0000000000000000 .data
0000000000000018 0000000400000001 R_BPF_64_64 0000000000000000 .data
-bash-4.4$ llvm-readelf -s g1.o
Symbol table '.symtab' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS g1.c
2: 0000000000000000 8 OBJECT LOCAL DEFAULT 4 a
3: 0000000000000008 4 OBJECT LOCAL DEFAULT 4 b
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 64 FUNC GLOBAL DEFAULT 2 test
-bash-4.4$ llvm-objdump -d g1.o
g1.o: file format ELF64-BPF
Disassembly of section .text:
0000000000000000 test:
0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
2: 79 11 00 00 00 00 00 00 r1 = *(u64 *)(r1 + 0)
3: 18 02 00 00 08 00 00 00 00 00 00 00 00 00 00 00 r2 = 8 ll
5: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0)
6: 0f 10 00 00 00 00 00 00 r0 += r1
7: 95 00 00 00 00 00 00 00 exit
-bash-4.4$
. from symbol table, static variable "a" is in section #4, offset 0.
. from symbol table, static variable "b" is in section #4, offset 8.
. the first relocation is against symbol #4:
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
and in-section offset 0 (see llvm-objdump result)
. the second relocation is against symbol #4:
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
and in-section offset 8 (see llvm-objdump result)
. therefore, the first relocation is for variable "a", and
the second relocation is for variable "b".
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 354954
Some platforms, e.g. Windows, support backtraces but don't have
BACKTRACE. Checking for BACKTRACE prevents Windows from having
backtraces.
Patch by Jason Mittertreiner!
llvm-svn: 354951
Add .stub to kernel stub function name so that it is different from kernel
name in device code. This is necessary to let debugger find correct symbol
for kernel.
Differential Revision: https://reviews.llvm.org/D58518
llvm-svn: 354948
