一直以来,我都维护了完整的 GCC 工具链构建工具 和 LLVM,Clang,libc++,libc++abi工具链构建工具 。 一方面是为了测试和体验新版本编译器的功能和利用一些更现代化的工具检查代码中的风险,另一方面也是为了给我得很多开源仓库做多版本适配。 其中所有的编译期依赖项(不包括 tar,awk等可执行程序的工具)都是自己构建的,这样也能管理好某些新版本组件需要的新版本依赖项,并且做到跨发行版兼容。同时很多发行版自带的 LLVM+Clang 套件都缺斤少两,有的缺少 clang-analyzer ,有的缺少 clang-format ,也有的缺少 libc++ 和 libc++abi 或者缺少sanitizer组件。我也是根据自己的需要编译并输出了大多数开发工具,甚至还有一些开发库以便二次开发(比如用libclang写工具来复用libcang的AST功能)。
我们有时候写一些基础性类库或者实验新功能的时候,常常需要使用到最新版本的GCC和Clang。一些Linux发行版的源里和一些工具链(比如MSYS2)里其实自带LLVM套件的包,LLVM 官网也提供一些常见平台的预编译包下载。 那为什么我们还要自己编译呢?如果有注意到的小伙伴可能会发现,很多平台的源和 LLVM 官网 里下载的预编译包,其实是缺失很多组件的。有些没有libc++和libc++abi(CentOS 8),有些没有Sanitizer相关的组件,有些缺失其他的组件。而Clang虽然支持GCC的libstdc++,但是一方面我们写基础性类库还是要优先考虑原生STL库的兼容性,另一方面Clang对libstdc++的支持也不是太好,特别是有些第三方库在这个组合下也是没有适配得很好,同时gdb和libc++的搭配有时候也不是很完善。 所以我们就需要一个组件尽可能开完整地包含LLVM,Clang,libc++,libc++abi还有其他周边工具(各类Sanitizer,clang-tiny,clang-analyzer等等)的工具链。
Clangen使用 ClangSharp解析头文件来完成一些中间代码的生成(如Rpc的注册代码, 桩代码, C++类导出到Lua的代码等). 而ClangSharp本身依赖了llvm, 以及自己的一个libClangSharp的库, windows和linux下需要编译一下llvm和这个库, 一般来说系统没变的情况下, 直接使用已经编译好的libclang.so/dll即可, 但有些时候遇到需要升级llvm到高版本的情况, 比如说我们之前碰到的情况 , llvm9在linux下运行速度异常(Windows下10S的流程, 在linux下处理同样的任务要快3分钟, 最后发现可能之前编译使用的是debug版本), 我们需要编译LLVM, 并且编译依赖llvm的libClangSharp, 官方文件比较简单, 而且配置项有一些问题, 可能导致不能正常编译, 所以这里记录下过程方便后续有相关需求的时候可以参照处理.
LLVM和Clang工具链的生成配置文件写得比较搓,所以略微麻烦,另外这个脚本没有经过多环境测试,不保证在其他Linux发行版里正常使用。
###ubuntu 12.04 安装llvm3.4、ios-lang交叉编译环境小记 在ubuntu 12.04上先安装gcc-4.8,然后安装llvm,clang,libcxx,libcxxabi.由于libcxx和libcxxabi相互依赖,需要两次安装libcxx。最后安装theos等开放的ios开发工具链 安装gcc-4.8如前文所述install gcc4.8 on ubuntu 12.04 安装llvm,clang /etc/apt/sources.list中添加如下两行:
只要你和程序打交道,了解编译器架构就会令你受益无穷——无论是分析程序效率,还是模拟新的处理器和操作系统。通过本文介绍,即使你对编译器原本一知半解,也能开始用LLVM,来完成有意思的工作。
因为有报告显示LLVM V10编译Rust语言性能居然降低了10%。虽然LLVM的主要目的是编译Clang的C/C++,但是还有有必要让LLVM跑起来更快才行。
为了实现对 Objective-C 新特性的支持,苹果公司结合LLVM改进GCC,从而衍生出了一个GCC分支,也就是LLVM GCC
首先,不管是Windows还是Linux版本CoreCLR的编译,都是在Windows10上进行的。
之前介绍了一点高通可信执行环境QSEE,我们知道QSEE是一种TEEOS,那么今天来了解下其编译工具链。 高通的可信执行环境---QSEE 先下载工具: 需要说明的是LLVM(Low Level V
当你心血来潮想学习Rust这门语言时,一定会用到Rustup来安装Rust。同时你可以会疑问toolchain是啥,target又是啥,为啥学其它编程语言没有这些概念,下面我们就一一解答你的疑问。
QBDI全名为QuarkslaB Dynamicbinary Instrumentation,它是一个模块化的跨平台以及跨架构的DBI框架。该工具目前支持Linux、macOS、Android、iOS和Windows操作系统,支持的架构有x86、x86-64、ARM和AArch64架构。QBDI的模块化特征意味着它不需要包含任何首选的注入方法,并且可以结合外部注入工具一起使用。QBDI包含了一个基于LD_PRELOAD的小型Linux以及一个动态可执行的macOS注入器(QBDIPreload),它们是QBDI的Python绑定基础,即pyQBDI。QBDI还整合了Frida,一个动态指令工具集。
PyTorch1.3以后添加了对移动端的支持,我曾尝试过将模型转入移动端,花了很多功夫,把检测+识别的所有代码都转成TorchScript之后,放到移动端运行,却发现在移动端的推理速度比PC慢了好几倍,不得不放弃这个方案。
前天早上开会还说这个 envoy 1.16 不知道什么时候发布,我们需要的几个新特性都在这个版本中,今天一看已经发布了,所以今天又测试了一波 1.16 上的例子。
在去年7月发布的Android FFmpeg系列01--编译与集成一文中我们采用的是ndk r21d+FFmpeg5.0.1的版本,一年过去,FFmpeg也迭代到了6.0的版本
目前主流编译平台有,GNU、MSVC、LLVM。因为rustc调用了llvm,因此我们以LLVM为例,我们从C语言的编译过程聊,再对比Rust,看它们的编译过程有何差异。
Cmake是跨平台构编译大型项目的工具,配合make工具和编译器我们理论上我们可以编译任何工程。具体的介绍就不多说了,不论是OpenCV还是Pytorch都是用cmake作为构建工具,当然还有很多很多工程项目使用它,这里不进行详细的介绍。
Emscripten是用于编译为使用LLVM构建的asm.js和WebAssembly的工具链,可让您以几乎本机的速度在Web上运行C和C ++,而无需插件。
下一代英特尔 C/C++ 编译器的表现会更加出色,因为它们将使用 LLVM 开源基础架构。
内容一览:TVM 共有三种安装方法:从源码安装、使用 Docker 镜像安装和 NNPACK Contrib 安装。本文重点介绍如何通过源码安装 TVM。
LLVM 的速度直接影响 rustc 的速度,因为rustc使用LLVM作为后端。
本文示例可见:https://github.com/ikuokuo/start-cpp20
Android 的安全模型由 Linux 内核强制执行,这将诱使攻击者将其视为攻击目标。我们在已发布的 Android 版本和 Android 9 上为加强内核投入了大量精力,我们将继续这项工作,通过将关注点放在基于编译器的安全缓解措施上以防止代码重用攻击。
前段时间试了把虚拟机CentOS下面的C/C++工程中的Makefile文件改用clang/clang++来编译,这篇文章主要是介绍如何在CentOS7.3系统编译安装最新的LLVM和Clang4.0.1。
在本系列的第 1 部分和第 2 部分,我们介绍了 eBPF 虚拟机内部工作原理,在第 3 部分我们研究了基于底层虚拟机机制之上开发和使用 eBPF 程序的主流方式。
长期以来,Rust 编程语言的一个目标都是能替代在操作系统内核开发中最常用的 C 语言。随着 Rust 的逐步成熟,许多开发人员越来越有兴趣在 Linux 内核中尝试 Rust。在 2020 (virtual) Linux Plumbers Conference 会议上,LLVM 这个微会议的诸多议题中就举办了一场讨论,关于 Linux 内核中接受 Rust 代码还有那些未解决的问题或者障碍。这是 2020 年活动中参加人数最多的一次会议,从中可以看出人们对这个议题有多么感兴趣了。
在C或C++等语言中工作的开发者可以使用两种相互竞争的编译器: GCC和LLVM。它们中的任何一种通常都可以完成工作。不过,Rust 的开发者目前只能使用基于LLVM的rustc编译器。虽然rustc工作得很好,但开发者也有合理的理由希望有一个替代品。事实证明,有两种不同的方法可以使用GCC编译Rust,虽然目前都还没有准备好。这两种方法的开发者都来到了2021年的 Linux Plumbers 大会[2],介绍他们的工作状况。
在这篇文章中,我将迅速调研一种跟踪的 Go 程序的新方法:基于 Linux 4.x eBPF 实现动态跟踪。如果你去搜索 Go 和 BPF,你会发现使用 BPF 接口的 Go 语言接口(例如,gobpf)。这不是我所探索的东西:我将使用 BPF 工具实现 Go 应用程序的性能分析和调试。
后来盯着 CMakeList,看到这些编译、link 优化项,心想也没有可能是这些的配置导致的:
我在知乎上开了一个新的专栏[1],想持续聊聊“向量数据库”相关的内容。本篇聊聊向量数据库领域,知名的开源技术项目:Milvus。
#68914 : 增量编译使用「SipHasher128」哈希算法来确定自上一次编译器调用以来更改了哪些代码。此PR极大地改善了从输入字节流中提取字节的过程(通过反复进行来确保它在big-endian和little-endian平台上均可工作),在大多数情况下,编译速度最多可提升13%。
Android Studio 2.2 及以后的版本默认使用CMake进行 NDK 编译, 其中最吸引人的地方是,在开发NDK程序时可以进行联机调试,这真是大在的方便了开发者开发NDK程序的效率了。 那么使用CMake编译NDK程序是否与我们之前介绍的使用ndk-build编译有很大的不同呢?下面我们就来一窥它的原理。
如果回显中显示CONFIG_INFO_BTF=y表示开启。如果未开启需要重新编译内核开启。
可能是疫情的原因,GCC好久没发布啦。最近总于又Release了,还是大版本。并且三大编译器对C++20的支持也都七七八八了。所以特意立贴庆祝一下,顺带更新一波构建脚本把这两年的一些改动列举一下。
在Liteos-a中,使用LLVM来编译程序。LLVM的本意是“Low Level Virtual Machine”,一个底层的虚拟机。但是它现在已经发展成了一种编译器(compiler)的框架系统。简单地说,LLVM可以取代GCC,LLVM容易扩展,可以提供更好的性能。
最权威的原始步骤可以参考github中关于此插件的README.md,如果时间允许的话,尽量多看几遍可以避免很多不必要的麻烦。
上一篇我们写了一个最基本的Hello Engine,并用Visual Studio的命令行工具,cl.exe进行了编译。
脚本大概思路就是下载如下所表示的组件所有源码,除llvm外的其他组件源代码解压到llvm/tools目录下,这样子源代码就全部准备好 BUILD_TARGET_COMPOMENTS="llvm clang compiler_rt libcxx libcxxabi clang_tools_extra lldb lld libunwind"; 接下来就是编译的过程了。
最近在根据项目需求疯狂撸 OpenCL ,FFmpeg 相关的文章落下了不少,后面也准备介绍下 OpenCL 在 Android 上的应用,另外 OpenCL 可以和 OpenGL 结合使用,非常有趣。
在android-ndk-r19c目录下toolchains文件夹中的llvm文件夹即为clang编译工具包
鸿蒙发布在gitee上 https://gitee.com/openHarmony 入门指导,以Hi3516DV300为例
2021 年 11 月,我们决定评估 arm64 架构在 Uber 的可行性。我们的大多数服务是用 Go 或 Java 编写的,但我们的构建系统只能编译成 x86_64。现在,得益于开源合作,Uber 拥有了一个独立于系统的构建工具链,可以无缝地支持多种架构。我们使用这个工具链来引导 arm64 主机。本文将分享我们是如何着手去做这件事情的,以及我们早期的想法、遇到的问题、达成的一些成就和未来的方向。
【GiantPandaCV导语】这篇文章主要是讲解了如何给Jetson Nano装机,以及在Jetson Nano上如何配置TVM并将MxNet的ResNet18跑起来获取分类结果,最后我们还体验了一下使用AutoTVM来提升ResNet50在Jetson Nano上的推理效率,AutoTune了一个Task(一共需要AutoTune 20个Task)之后可以将ResNet50的推理速度做到150ms跑完一张图片(224x224x3),从上面的BenchMark可以看到TensorRT在FP32的时候大概能做到50-60ms推理一张图片(224x224x3)。本文所有实验代码均可以在这里找到:https://github.com/BBuf/tvm_learn/blob/main/relay ,如果你对学习TVM感兴趣可以考虑点个star。
微软的 Ryan Levick 大神提到,LLVM13 的最新的 pass manager 进展让 Rust 的编译速度整体提高 5~20%。目前 LLVM13 还在 nightly 状态。很快估计能惠及到 Rust 这边来。
Nimcrypt2一款功能强大的PE封装器和加载器,该工具基于Nim开发,除了PE之外,该工具还支持对.NET、和原始Shellcode进行封装和加载。该工具能够通过尝试绕过AV/EDR来检测系统的安全性能。
几乎所有编程接口都可见于:内核源代码的include/uapi/linux/bpf.h文件中
Kotlin Native是一种将Kotlin源码编译成不需要任何VM支持的目标平台二进制数据的技术,编译后的二进制数据可以直接运行在目标平台上,它主要包含一个基于LLVM的后端编译器的和一个Kotlin本地运行时库。设计Kotlin Native的目的是为了支持在非JVM环境下进行编程,如在嵌入式平台和iOS环境下,如此一来,Kotlin就可以运行在非JVM平台环境下。
领取专属 10元无门槛券
手把手带您无忧上云