Summary: Fixes the bots - I moved LLVMSetSubprogram into the DIBuilder bindings, so the Go bindings need to move as well.
Reviewers: whitequark
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45402
llvm-svn: 329505
This patch adds a set of unstable C API bindings to the DIBuilder interface for
creating structure, function, and aggregate types.
This patch also removes the existing implementations of these functions from
the Go bindings and updates the Go API to fit the new C APIs.
llvm-svn: 328953
X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET).
IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp.
The `nocf_check` attribute has two roles in the context of X86 IBT technology:
1. Appertains to a function - do not add ENDBR instruction at the beginning of the function.
2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction.
This patch implements `nocf_check` context for Indirect Branch Tracking.
It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks.
Differential Revision: https://reviews.llvm.org/D41879
llvm-svn: 327767
https://github.com/golang/go/issues/23672
By this change, building a Go code with LLVM Go bindings causes a compilation error as follows.
go build llvm.org/llvm/bindings/go/llvm: invalid flag in #cgo LDFLAGS: -Wl,-headerpad_max_install_names
llvm-go tool generates cgo LDFLAGS directive from `llvm-config --ldflags` and it contains -Wl,option options. But -Wl,option is banned by default. To avoid this problem, we need to set $CGO_LDFLAGS_ALLOW environment variable to notify a compiler that the flags should be allowed.
$ export CGO_LDFLAGS_ALLOW='-Wl,(-search_paths_first|-headerpad_max_install_names)'
By default for go 1.10 and go 1.9.5 these options should appear in the accepted set of options, however, if you're running into the error it's useful to have this documented.
Patch by Ryuichi Hayashida
llvm-svn: 325946
Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
llvm-svn: 315590
Account for the possibility of LLVMDumpType() not being available with
NDEBUG in the OCaml bindings. If it is not built into LLVM, make
the dump function raise an exception.
Since rL293359, the dump functions are built only if either NDEBUG is
not defined, or LLVM_ENABLE_DUMP is defined. As a result, if the dump
functions are not built in LLVM, the dynamic OCaml libraries fail to
load due to undefined LLVMDumpType symbol.
Differential Revision: https://reviews.llvm.org/D35899
llvm-svn: 309321
This patch adds LLVMGetSubtypes to Go API (as Type.Subtypes), tests included.
Patch by Ekaterina Vaartis!
Differential Revision: https://reviews.llvm.org/D33901
llvm-svn: 304968
The C functions added are LLVMGetNumContainedTypes and
LLVMGetSubtypes.
The OCaml function added is Llvm.subtypes.
Patch by Ekaterina Vaartis.
Differential Revision: https://reviews.llvm.org/D33677
llvm-svn: 304709
Summary:
This seems like an uncontroversial first step toward providing access to the metadata hierarchy that now exists in LLVM. This should allow for good debug info support from C.
Future plans are to deprecate API that take mixed bags of values and metadata (mainly the LLVMMDNode family of functions) and migrate the rest toward the use of LLVMMetadataRef.
Once this is in place, mapping of DIBuilder will be able to start.
Reviewers: mehdi_amini, echristo, whitequark, jketema, Wallbraker
Reviewed By: Wallbraker
Subscribers: Eugene.Zelenko, axw, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D19448
llvm-svn: 300447
Summary:
Currently Go binding only has SetCurrentDebugLocation method.
I added GetCurrentDebugLocation method to IRBuilder instance.
I added this because I want to save current debug location, change debug location temporary and restore the saved one finally.
This is useful when source location jumps and goes back after while LLVM IR generation.
I also added tests for this to ir_test.go.
I confirmed that all test passed with this patch based on r298890
Patch by Ryuichi Hayashida!
Differential Revision: https://reviews.llvm.org/D31415
llvm-svn: 299185
Summary:
The C++ side of the Go bindings were updated in r286085, r286086, and r286087,
but those did not remove this type.
Reviewers: djasper
Subscribers: axw
Differential Revision: https://reviews.llvm.org/D26337
llvm-svn: 286131
In futher patches we shall have alignment field added to DIVariable family
and switching from uint64_t to uint32_t will save 4 bytes per variable.
Differential Revision: https://reviews.llvm.org/D25620
llvm-svn: 284482
Add a OCAML_INSTALL_PATH variable that can be used to control
the install path for OCaml libraries. The new variable defaults to
${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from
the OCaml compiler. Install libraries into "llvm" subdirectory.
This fixes two issues:
1. OCaml library directories differ between systems, and 'lib/ocaml' is
incorrect e.g. on amd64 Gentoo where OCaml is installed
in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml
compiler using 'ocamlc -where' (which is already used to set
OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages.
2. The top-level directory is reserved for the standard library, and has
precedence over local directory in search path. As a result, OCaml
preferred the files installed along with previous LLVM version over the
source tree when building a new version, resulting in two versions being
mixed during the build. The new layout is used commonly by other OCaml
packages, and findlib is able to find the LLVM libraries successfully.
Bug: https://bugs.gentoo.org/559134
Bug: https://bugs.gentoo.org/559624
Differential Revision: https://reviews.llvm.org/D24354
llvm-svn: 282895
That is, add build system support for building the OCaml bindings
against preinstalled LLVM libraries. This is important for package
managers such as OPAM, because OCaml libraries need to be built
against a specific OCaml compiler installation.
llvm-svn: 280642
Nearly all the changes to this pass have been done while maintaining and
updating other parts of LLVM. LLVM has had another pass, SROA, which
has superseded ScalarReplAggregates for quite some time.
Differential Revision: http://reviews.llvm.org/D21316
llvm-svn: 272737
At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.
This is the first part of http://reviews.llvm.org/D19094
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266379
The llvm_string_of_message function, called by llvm_raise, calls
LLVMDisposeMessage, which expects the message to be dynamically
allocated; it fails freeing the message otherwise. So always
dynamically allocate with LLVMCreateMessage.
Differential Revision: http://reviews.llvm.org/D18675
llvm-svn: 265116
Expose LLVMCreateTargetMachineData as data_layout.
As r263530 did for go. From that commit: "LLVMGetTargetDataLayout was
removed from the C API, and then TargetMachine.TargetData was removed.
Later, LLVMCreateTargetMachineData was added to the C API"
Differential Revision: http://reviews.llvm.org/D18677
llvm-svn: 265115
* LLVMDisposeMessage lives in llvm-c/Core.h, include this file where necessary
* LLVMAddTargetData has been removed, follow suit in the bindings
Differential Revision: http://reviews.llvm.org/D18633
llvm-svn: 265001
Summary:
LLVMGetTargetDataLayout was removed from the C API,
and then TargetMachine.TargetData was removed. Later,
LLVMCreateTargetMachineData was added to the C API,
and we now expose this via the Go API.
Reviewers: deadalnix, pcc
Subscribers: cierniak, llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D18173
llvm-svn: 263530
