Commit Graph

249 Commits

Author SHA1 Message Date
Sean Fertile f09d54ed2a Boilerplate for producing XCOFF object files from the PowerPC backend.
Stubs out a number of the classes needed to produce a new object file format
(XCOFF) for the powerpc-aix target. For testing input is an empty module which
produces an object file with just a file header.

Differential Revision: https://reviews.llvm.org/D61694

llvm-svn: 365541
2019-07-09 19:21:01 +00:00
Fangrui Song c99d9aee00 MCContext: Delete unused functions
llvm-svn: 363674
2019-06-18 12:30:06 +00:00
Jason Liu 60ec248148 [AIX] Implement function descriptor on SDAG
Summary:
(1) Function descriptor on AIX
On AIX, a called routine may have 2 distinct symbols associated with it:
 * A function descriptor (Name)
 * A function entry point (.Name)

The descriptor structure on AIX is the same as those in the ELF V1 ABI:
 * The address of the entry point of the function.
 * The TOC base address for the function.
 * The environment pointer.

The descriptor symbol uses the same name as the source level function in C.
The function entry point is analogous to the symbol we would generate for a
 function in a non-descriptor-based ABI, except that it is renamed by
prepending a ".".

Which symbol gets referenced depends on the context:
 * Taking the address of the function references the descriptor symbol.
 * Calling the function references the entry point symbol.

(2) Speaking of implementation on AIX, for direct function call target, we
 create proper MCSymbol SDNode(e.g . ".foo") while constructing SDAG to
 replace original TargetGlobalAddress SDNode. Then down the path, we can
 take advantage of this MCSymbol.

Patch by: Xiangling_L

Reviewed by: sfertile, hubert.reinterpretcast, jasonliu, syzaara

Differential Revision: https://reviews.llvm.org/D62532

llvm-svn: 362735
2019-06-06 19:13:36 +00:00
Paul Robinson 116e8d4876 [DebugInfo] Handle -main-file-name correctly for asm source.
This option provides only the base filename, not a full relative path.

Part of the fix for PR41839.

Differential Revision: https://reviews.llvm.org/D62071

llvm-svn: 361245
2019-05-21 11:52:27 +00:00
Ali Tamur 783d84bb39 [llvm] Prevent duplicate files in debug line header in dwarf 5: another attempt
Another attempt to land the changes in debug line header to prevent duplicate
files in Dwarf 5. I rolled back my previous commit because of a mistake in
generating the object file in a test. Meanwhile, I addressed some offline
comments and changed the implementation; the largest difference is that
MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I
also merged the patch to fix two lld tests that will strt to fail into this
patch.

Original Commit:

https://reviews.llvm.org/D59515

Original Message:
Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.

The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)

With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf
5) However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.

llvm-svn: 358732
2019-04-19 02:26:56 +00:00
Eric Christopher 798e83b5d6 NFC: Move API uses of MD5::MD5Result to Optional rather than a pointer.
Differential Revision: https://reviews.llvm.org/D60290

llvm-svn: 357736
2019-04-04 23:34:38 +00:00
Ali Tamur 02e96648d7 Revert "[llvm] Reapply "Prevent duplicate files in debug line header in dwarf 5.""
This reverts commit rL357020.

The commit broke the test llvm/test/tools/llvm-objdump/embedded-source.test
on some builds including clang-ppc64be-linux-multistage,
clang-s390x-linux, clang-with-lto-ubuntu, clang-x64-windows-msvc,
llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast (and others).

llvm-svn: 357026
2019-03-26 20:05:27 +00:00
Ali Tamur 2f5cd03a3f [llvm] Reapply "Prevent duplicate files in debug line header in dwarf 5."
Reapply rL356941 after regenerating the object file in the failing test
llvm/test/tools/llvm-objdump/embedded-source.test from source.

Original commit message:

[llvm] Prevent duplicate files in debug line header in dwarf 5.

Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.

The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)

With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5)
However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.

Tags: #llvm, #debug-info

Differential Revision: https://reviews.llvm.org/D59515

llvm-svn: 357018
2019-03-26 18:53:23 +00:00
Ali Tamur fdce82a814 Revert "[llvm] Prevent duplicate files in debug line header in dwarf 5."
This reverts commit 312ab05887.

My commit broke the build; I will revert and find out what happened.

llvm-svn: 356951
2019-03-25 21:09:07 +00:00
Ali Tamur 312ab05887 [llvm] Prevent duplicate files in debug line header in dwarf 5.
Summary:

Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.

The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)

With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5)
However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.

Reviewers: dblaikie, probinson, aprantl, espindola

Reviewed By: probinson

Subscribers: emaste, jvesely, nhaehnle, aprantl, javed.absar, arichardson, hiraditya, MaskRay, rupprecht, jdoerfert, llvm-commits

Tags: #llvm, #debug-info

Differential Revision: https://reviews.llvm.org/D59515

llvm-svn: 356941
2019-03-25 20:08:00 +00:00
Jason Liu a03ae73c29 Add XCOFF triple object format type for AIX
This patch adds an XCOFF triple object format type into LLVM.
This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform.

Differential Revision: https://reviews.llvm.org/D58930

llvm-svn: 355989
2019-03-12 22:01:10 +00:00
Paul Robinson d8632c92a7 Try to fix Windows bots after r355226.
Windows has two path separator characters.

llvm-svn: 355235
2019-03-01 22:28:13 +00:00
Paul Robinson 1ca25763f0 [DWARF] Make -g with empty assembler source work better.
This was sometimes causing clang or llvm-mc to crash, and in other
cases could emit a bogus DWARF line-table header. I did an interim
patch in r352541; this patch should be a cleaner and more complete
fix, and retains the test.

Addresses PR40538.

Differential Revision: https://reviews.llvm.org/D58750

llvm-svn: 355226
2019-03-01 20:58:04 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Eli Friedman a6e3a823b3 Revert BTF commit series.
The initial patch was not reviewed, and does not have any tests;
it should not have been merged.

This reverts 344395, 344390, 344387, 344385, 344381, 344376,
and 344366.

llvm-svn: 344405
2018-10-12 19:41:05 +00:00
Yonghong Song 6c2327a09e [BPF] Add BTF generation for BPF target
BTF is the debug format for BPF, a kernel virtual machine
and widely used for tracing, networking and security, etc ([1]).

Currently only instruction streams are passed to kernel,
the kernel verifier verifies them before execution. In order to
provide better visibility of bpf programs to user space
tools, some debug information, e.g., function names and
debug line information are desirable for kernel so tools
can get such information with better annotation
for jited instructions for performance or other reasons.

The dwarf is too complicated in kernel and for BPF.
Hence, BTF is designed to be the debug format for BPF ([2]).
Right now, pahole supports BTF for types, which
are generated based on dwarf sections in the ELF file.

In order to annotate performance metrics for jited bpf insns,
it is necessary to pass debug line info to the kernel.
Furthermore, we want to pass the actual code to the
kernel because of the following reasons:

. bpf program typically is small so storage overhead
  should be small.
. in bpf land, it is totally possible that
  an application loads the bpf program into the
  kernel and then that application quits, so
  holding debug info by the user space application
  is not practical.
. having source codes directly kept by kernel
  would ease deployment since the original source
  code does not need ship on every hosts and
  kernel-devel package does not need to be
  deployed even if kernel headers are used.

The only reliable time to get the source code is
during compilation time. This will result in both more
accurate information and easier deployment as
stated in the above.

Another consideration is for JIT. The project like bcc
use MCJIT to compile a C program into bpf insns and
load them to the kernel ([3]). The generated BTF sections
will be readily available for such cases as well.

This patch implemented generation of BTF info in llvm
compiler. The BTF related sections will be generated
when both -target bpf and -g are specified. Two sections
are generated:
  .BTF contains all the type and string information, and
  .BTF.ext contains the func_info and line_info.

The separation is related to how two sections are used
differently in bpf loader, e.g., linux libbpf ([4]).
The .BTF section can be loaded into the kernel directly
while .BTF.ext needs loader manipulation before loading
to the kernel. The format of the each section is roughly
defined in llvm:include/llvm/MC/MCBTFContext.h and
from the implementation in llvm:lib/MC/MCBTFContext.cpp.
A later example also shows the contents in each section.

The type and func_info are gathered during CodeGen/AsmPrinter
by traversing dwarf debug_info. The line_info is
gathered in MCObjectStreamer before writing to
the object file. After all the information is gathered,
the two sections are emitted in MCObjectStreamer::finishImpl.

With cmake CMAKE_BUILD_TYPE=Debug, the compiler can
dump out all the tables except insn offset, which
will be resolved later as relocation records.
The debug type "btf" is used for BTFContext dump.

Dwarf tests the debug info generation with
llvm-dwarfdump to decode the binary sections and
check whether the result is expected. Currently
we do not have such a tool yet. We will implement
btf dump functionality in bpftool ([5]) as the bpftool is
considered the recommended tool for bpf introspection.
The implementation for type and func_info is tested
with linux kernel test cases. The line_info is visually
checked with dump from linux kernel libbpf ([4]) and
checked with readelf dumping section raw data.

Note that the .BTF and .BTF.ext information will not
be emitted to assembly code and there is no assembler
support for BTF either.

In the below, with a clang/llvm built with CMAKE_BUILD_TYPE=Debug,
Each table contents are shown for a simple C program.

  -bash-4.2$ cat -n test.c
     1  struct A {
     2    int a;
     3    char b;
     4  };
     5
     6  int test(struct A *t) {
     7    return t->a;
     8  }
  -bash-4.2$ clang -O2 -target bpf -g -mllvm -debug-only=btf -c test.c
  Type Table:
  [1] FUNC name_off=1 info=0x0c000001 size/type=2
        param_type=3
  [2] INT name_off=12 info=0x01000000 size/type=4
        desc=0x01000020
  [3] PTR name_off=0 info=0x02000000 size/type=4
  [4] STRUCT name_off=16 info=0x04000002 size/type=8
        name_off=18 type=2 bit_offset=0
        name_off=20 type=5 bit_offset=32
  [5] INT name_off=22 info=0x01000000 size/type=1
        desc=0x02000008

  String Table:
  0 :
  1 : test
  6 : .text
  12 : int
  16 : A
  18 : a
  20 : b
  22 : char
  27 : test.c
  34 : int test(struct A *t) {
  58 :   return t->a;

  FuncInfo Table:
  sec_name_off=6
        insn_offset=<Omitted> type_id=1

  LineInfo Table:
  sec_name_off=6
        insn_offset=<Omitted> file_name_off=27 line_off=34 line_num=6 column_num=0
        insn_offset=<Omitted> file_name_off=27 line_off=58 line_num=7 column_num=3
  -bash-4.2$ readelf -S test.o
  ......
    [12] .BTF              PROGBITS         0000000000000000  0000028d
       00000000000000c1  0000000000000000           0     0     1
    [13] .BTF.ext          PROGBITS         0000000000000000  0000034e
       0000000000000050  0000000000000000           0     0     1
    [14] .rel.BTF.ext      REL              0000000000000000  00000648
       0000000000000030  0000000000000010          16    13     8
  ......
  -bash-4.2$

The latest linux kernel ([6]) can already support .BTF with type information.
The [7] has the reference implementation in linux kernel side
to support .BTF.ext func_info. The .BTF.ext line_info support is not
implemented yet. If you have difficulty accessing [6], you can
manually do the following to access the code:

  git clone https://github.com/yonghong-song/bpf-next-linux.git
  cd bpf-next-linux
  git checkout btf

The change will push to linux kernel soon once this patch is landed.

References:
[1]. https://www.kernel.org/doc/Documentation/networking/filter.txt
[2]. https://lwn.net/Articles/750695/
[3]. https://github.com/iovisor/bcc
[4]. https://github.com/torvalds/linux/tree/master/tools/lib/bpf
[5]. https://github.com/torvalds/linux/tree/master/tools/bpf/bpftool
[6]. https://github.com/torvalds/linux
[7]. https://github.com/yonghong-song/bpf-next-linux/tree/btf

Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>

Differential Revision: https://reviews.llvm.org/D52950

llvm-svn: 344366
2018-10-12 17:01:46 +00:00
Fangrui Song 58963e4396 Fix typos. NFC
llvm-svn: 341740
2018-09-08 02:04:20 +00:00
George Rimar 9fbecc97ae Revert r340904 "[llvm-mc] - Allow to set custom flags for debug sections."
It broke PPC64 BB:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/23252

llvm-svn: 340906
2018-08-29 09:04:52 +00:00
George Rimar 999d1ce517 [llvm-mc] - Allow to set custom flags for debug sections.
I am experimenting with a single split dwarf (.dwo sections in .o files).
I want to make linker to ignore .dwo sections in .o, for that I am trying to add
SHF_EXCLUDE flag ("E") for them in my asm sample.

I found that currently, it is impossible to add any flag for debug sections using llvm-mc.

That happens because we have a set of predefined unique sections created early with default flags:
https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCObjectFileInfo.cpp#L391

This patch allows a user to add any flags he wants.

I had to edit TargetLoweringObjectFileImpl.cpp to set MetaData type for debug sections.
Their kind was Data by default (so they were allocatable) and so after changes introduced by
this patch the SHF_ALLOC flag was applied for them, what does not make sense for debug sections.
One of OrcJITTests tests failed because of that.

Differential revision: https://reviews.llvm.org/D51361

llvm-svn: 340904
2018-08-29 08:42:02 +00:00
Reid Kleckner 689f773317 [codeview] Clean up machinery for deferring .cv_loc emission
Now that we create the label at the point of the directive, we don't
need to set the "current CV location", and then later when we emit the
next instruction, create a label for it and emit it.

DWARF still defers the labels used in .debug_loc until the next
instruction or value, for reasons unknown.

llvm-svn: 340883
2018-08-28 23:25:59 +00:00
Jonas Devlieghere 26ddf274d7 Use debug-prefix-map for AT_NAME
AT_NAME was being emitted before the directory paths were remapped. This
ensures that all paths are remapped before anything is emitted.

An additional test case has been added.

Note that this only works if the replacement string is an absolute path.
If not, then AT_decl_file believes the new path is a relative path, and
joins that path with the compilation directory. I do not know of a good
way to resolve this.

Patch by: Siddhartha Bagaria (starsid)

Differential revision: https://reviews.llvm.org/D49169

llvm-svn: 336793
2018-07-11 12:30:35 +00:00
Paul Robinson c17c8bf749 Support -fdebug-prefix-map in llvm-mc. This is useful to omit the
debug compilation dir when compiling assembly files with -g.
Part of PR38050.

Patch by Siddhartha Bagaria!

Differential Revision: https://reviews.llvm.org/D48988

llvm-svn: 336680
2018-07-10 14:41:54 +00:00
Paul Robinson 11539b0969 [DWARFv5] Allow ".loc 0" to refer to the root file.
DWARF v5 explicitly represents file #0 in the line table.  Prior
versions did not, so ".loc 0" is still an error in those cases.

Differential Revision: https://reviews.llvm.org/D48452

llvm-svn: 335350
2018-06-22 14:16:11 +00:00
Sam Clegg 105bdc2557 [WebAssembly] MC: Add compile-twice test and fix corresponding bug
Differential Revision: https://reviews.llvm.org/D47398

llvm-svn: 333494
2018-05-30 02:57:20 +00:00
Sam Clegg b210c64b28 [WebAssembly] Create section start symbols automatically for all sections
These symbols only get included in the output symbols table if
they are used in a relocation.

This behaviour matches more closely the ELF object writer.

Differential Revision: https://reviews.llvm.org/D46561

llvm-svn: 332005
2018-05-10 17:38:35 +00:00
Sam Clegg 4d57fbd02a [WebAssembly] MC: Create and use first class section symbols
Differential Revision: https://reviews.llvm.org/D46335

llvm-svn: 331413
2018-05-02 23:11:38 +00:00
Reid Kleckner 2c6430fe3c [codeview] Ignore .cv_loc directives at the end of a function
If no data or instructions are emitted after a location directive, we
should clear the cv_loc when we change sections, or it will be emitted
at the beginning of the next section. This violates our invariant that
all .cv_loc directives belong to the same section. Add clearer
assertions for this.

llvm-svn: 330884
2018-04-25 23:34:15 +00:00
Scott Linder 16c7bdaf32 [DebugInfo] Support DWARF v5 source code embedding extension
In DWARF v5 the Line Number Program Header is extensible, allowing values with
new content types. In this extension a content type is added,
DW_LNCT_LLVM_source, which contains the embedded source code of the file.

Add new optional attribute for !DIFile IR metadata called source which contains
source text. Use this to output the source to the DWARF line table of code
objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM
to support optional source.

Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output
format of llvm-dwarfdump to make room for the new attribute on file_names
entries, and support embedded sources for the -source option in llvm-objdump.

Differential Revision: https://reviews.llvm.org/D42765

llvm-svn: 325970
2018-02-23 23:01:06 +00:00
Paul Robinson 70def12a96 [DWARFv5] Turn an assert into a diagnostic. Hand-coded assembler files
should not trigger assertions.

Differential Revision: https://reviews.llvm.org/D43152

llvm-svn: 325831
2018-02-22 21:03:33 +00:00
Sam Clegg d423f0d290 [WebAssemlby] MC: Don't write COMDAT symbols as global imports
This was causing undefined references at link time in lld.

Differential Revision: https://reviews.llvm.org/D41959

llvm-svn: 322309
2018-01-11 20:35:17 +00:00
Paul Robinson 29f5f987f1 [DWARFv5] MC support for MD5 file checksums
Extend .file directive syntax to allow specifying an MD5 checksum for
the source file.  Emit the checksums in DWARF v5 line tables.

llvm-svn: 322134
2018-01-09 23:31:48 +00:00
Sam Clegg 12fd3da9d1 [WebAssembly] MC: Fix crash when -g specified.
At this point we don't output any debug sections or thier
relocations.

Differential Revision: https://reviews.llvm.org/D39076

llvm-svn: 316240
2017-10-20 21:28:38 +00:00
Sam Clegg 2176a9f2a3 [WebAssembly] Remove flags from MCSectionWasm
Looks like these were copied from the ELF sections but
don't apply to Wasm and were not used anywhere.

Also remove unused Wasm methods in MCContext.

Differential Revision: https://reviews.llvm.org/D37633

llvm-svn: 313058
2017-09-12 18:31:24 +00:00
Zachary Turner 264b5d9e88 Move Object format code to lib/BinaryFormat.
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.

Differential Revision: https://reviews.llvm.org/D33843

llvm-svn: 304864
2017-06-07 03:48:56 +00:00
Chandler Carruth 6bda14b313 Sort the remaining #include lines in include/... and lib/....
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787
2017-06-06 11:49:48 +00:00
Evgeniy Stepanov 43dcf4d330 Fix asm printing of associated sections.
Make MCSectionELF::AssociatedSection be a link to a symbol, because
that's how it works in the assembly, and use it in the asm printer.

llvm-svn: 297769
2017-03-14 19:28:51 +00:00
Evgeniy Stepanov 00400d36c9 Disallow redefinition of section symbols.
Differential Revision: https://reviews.llvm.org/D30235

llvm-svn: 296180
2017-02-24 21:44:58 +00:00
Evgeniy Stepanov 0338ce83cd Initialize MCContext::InlineSrcMgr in the constructor.
Found with ASan (and a local source change) on test/CodeGen/XCore/section-name.ll.

llvm-svn: 296179
2017-02-24 21:44:52 +00:00
Dan Gohman 18eafb6c68 [WebAssembly] Add skeleton MC support for the Wasm container format
This just adds the basic skeleton for supporting a new object file format.
All of the actual encoding will be implemented in followup patches.

Differential Revision: https://reviews.llvm.org/D26722

llvm-svn: 295803
2017-02-22 01:23:18 +00:00
Eugene Zelenko d96089b248 [MC] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
Same changes in files affected by reduced MC headers dependencies.

llvm-svn: 295009
2017-02-14 00:33:36 +00:00
Rafael Espindola dc1c3011fd Make it possible to set SHF_LINK_ORDER explicitly.
This will make it possible to add support for gcing user metadata
(asan for example).

llvm-svn: 294589
2017-02-09 14:59:20 +00:00
Sanne Wouda 2933875cc2 [Assembler] Enable nicer diagnostics for inline assembly.
Fixed test.

Summary:
Enables source location in diagnostic messages from the backend.  This
is after parsing, during finalization.  This requires the SourceMgr, the
inline assembly string buffer, and DiagInfo to still be alive after
EmitInlineAsm returns.

This patch creates a single SourceMgr for inline assembly inside the
AsmPrinter.  MCContext gets a pointer to this SourceMgr.  Using one
SourceMgr per call to EmitInlineAsm would make it difficult for
MCContext to figure out in which SourceMgr the SMLoc is located, while a
single SourceMgr can figure it out if it has multiple buffers.

The Str argument to EmitInlineAsm is copied into a buffer and owned by
the inline asm SourceMgr.  This ensures that DiagHandlers won't print
garbage.  (Clang emits a "note: instantiated into assembly here", which
refers to this string.)

The AsmParser gets destroyed before finalization, which means that the
DiagHandlers the AsmParser installs into the SourceMgr will be stale.
Restore the saved DiagHandlers.

Since now we're using just one SourceMgr for multiple inline asm
strings, we need to tell the AsmParser which buffer it needs to parse
currently.  Hand a buffer id -- returned from SourceMgr::
AddNewSourceBuffer -- to the AsmParser.

Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet

Reviewed By: rnk

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29441
    

llvm-svn: 294458
2017-02-08 14:48:05 +00:00
Diana Picus 79add417b4 Revert "[Assembler] Enable nicer diagnostics for inline assembly."
This reverts commit r294433 because it seems it broke the buildbots.

llvm-svn: 294448
2017-02-08 14:02:16 +00:00
Sanne Wouda 09adc245ea [Assembler] Enable nicer diagnostics for inline assembly.
Summary:
Enables source location in diagnostic messages from the backend.  This
is after parsing, during finalization.  This requires the SourceMgr, the
inline assembly string buffer, and DiagInfo to still be alive after
EmitInlineAsm returns.

This patch creates a single SourceMgr for inline assembly inside the
AsmPrinter.  MCContext gets a pointer to this SourceMgr.  Using one
SourceMgr per call to EmitInlineAsm would make it difficult for
MCContext to figure out in which SourceMgr the SMLoc is located, while a
single SourceMgr can figure it out if it has multiple buffers.

The Str argument to EmitInlineAsm is copied into a buffer and owned by
the inline asm SourceMgr.  This ensures that DiagHandlers won't print
garbage.  (Clang emits a "note: instantiated into assembly here", which
refers to this string.)

The AsmParser gets destroyed before finalization, which means that the
DiagHandlers the AsmParser installs into the SourceMgr will be stale.
Restore the saved DiagHandlers.

Since now we're using just one SourceMgr for multiple inline asm
strings, we need to tell the AsmParser which buffer it needs to parse
currently.  Hand a buffer id -- returned from SourceMgr::
AddNewSourceBuffer -- to the AsmParser.

Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet

Reviewed By: rnk

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29441

llvm-svn: 294433
2017-02-08 10:20:07 +00:00
Rafael Espindola 13a79bbfe5 Change how we handle section symbols on ELF.
On ELF every section can have a corresponding section symbol. When in
an assembly file we have

.quad .text

the '.text' refers to that symbol.

The way we used to handle them is to leave .text an undefined symbol
until the very end when the object writer would map them to the
actual section symbol.

The problem with that is that anything before the end would see an
undefined symbol. This could result in bad diagnostics
(test/MC/AArch64/label-arithmetic-diags-elf.s), or incorrect results
when using the asm streamer (est/MC/Mips/expansion-jal-sym-pic.s).

Fixing this will also allow using the section symbol earlier for
setting sh_link of SHF_METADATA sections.

This patch includes a few hacks to avoid changing our behaviour when
handling conflicts between section symbols and other symbols. I
reported pr31850 to track that.

llvm-svn: 293936
2017-02-02 21:26:06 +00:00
Prakhar Bahuguna 52a7dd7d78 [ARM] Implement execute-only support in CodeGen
This implements execute-only support for ARM code generation, which
prevents the compiler from generating data accesses to code sections.
The following changes are involved:

* Add the CodeGen option "-arm-execute-only" to the ARM code generator.
* Add the clang flag "-mexecute-only" as well as the GCC-compatible
  alias "-mpure-code" to enable this option.
* When enabled, literal pools are replaced with MOVW/MOVT instructions,
  with VMOV used in addition for floating-point literals. As the MOVT
  instruction is required, execute-only support is only available in
  Thumb mode for targets supporting ARMv8-M baseline or Thumb2.
* Jump tables are placed in data sections when in execute-only mode.
* The execute-only text section is assigned section ID 0, and is
  marked as unreadable with the SHF_ARM_PURECODE flag with symbol 'y'.
  This also overrides selection of ELF sections for globals.

llvm-svn: 289784
2016-12-15 07:59:08 +00:00
Mandeep Singh Grang 9a561aa34c [llvm] Fix D26214: Move error handling out of MC and to the callers.
Summary: Related clang patch; https://reviews.llvm.org/D27360

Reviewers: t.p.northover, grosbach, compnerd, echristo

Subscribers: compnerd, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D27359

llvm-svn: 288763
2016-12-06 02:49:17 +00:00
Dan Gohman abceeeee5d [MC] Generalize MCContext's SectionSymbols field.
Change SectionSymbols so that it doesn't hard-code ELF types, so that
it can be used for non-ELF targets.

llvm-svn: 288607
2016-12-03 23:55:57 +00:00
Mandeep Singh Grang 32360071a0 [llvm] Implement support for -defsym assembler option
Summary:
Changes to llvm-mc to move common logic to separate function.

Related clang patch: https://reviews.llvm.org/D26213

Reviewers: rafael, t.p.northover, colinl, echristo, rengolin

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D26214

llvm-svn: 288396
2016-12-01 18:42:04 +00:00
Eric Christopher 8e94895555 Tidy spelling and grammar.
llvm-svn: 282672
2016-09-29 02:03:44 +00:00