lldb

Xcode 中的调试技巧与我们的日常开发息息相关，而这些调试技巧在我们解决Bug时，常常有事半功倍的作用，经常会用到的有各种断点 和 命令。而这些调试技巧也经常会在面试中问到，所以不知道的就来看看吧。 调试主要观看区 调试命令 在上图中，右侧绿色区域就是Log 输出区，在 Log 输出区可以使用一些命令，来辅助调试。 那有哪些调试命令呢？ 想要看所有的调试命令，可以在上图的右侧区域输入 help ，就会列出所有的调试命令。 本文就介绍几个使用频率比较高的，其他就查看后，自行了解吧。 1. p 命令 -- ('expression --') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. p 命令是 print 命令的简写，使用p 命令可以查看基本数据类型的值，但是如果 使用 p 命令 查看的是对象，那么只会返回对象的指针地址。 p 命令后面除了可以接 变量、常量，还可以接 表达式。（❌但是不可以使用宏❌） 2. po 命令 po 命令可以理解为打印对象。功能与 p 命令类似，所以也是可以打印 常量、变量，打印表达式返回的对象等。（❌也不可以打印宏❌） p 和 po 使用范例 当然，这些打印功能，除了使用命令外

更正了顺序， 之前不知道怎么回事，内容顺序乱了 力求完美、详细，所以希望懂的人留言指点一下。 目前已经开始添加原理解释，希望大家能分享一些gcc gdb C语言等方面优秀链接 　　后续会慢慢增添内容，修正不足。 希望这篇文章能带大家入坑。 Ps.2019年消息：VSCODE已支持全局配置，C/Cpp插件也支持UI界面设置。 具体请看官网或利用搜索引擎寻找资料 请耐心看完，因为这能让你了解什么是IDE、调试、运行和命令行以及系统和程序之间的关系 如果只是想找三个文件的配置方法，请点下面导航。（其实这三个文件配置并不难，难的是没用过gcc g++ gdb，当你稍微地使用之后，配置自然是水到渠成） 基本上各平台配置内容的差异只在于那个include路径（疯狂使用搜索引擎），所以只要写下正确路径，其他就没什么大问题了 目录书签导航 下载安装（2个软件） 配置MSYS2环境 && 换源 安装Mingw-w64编译工具 变量配置 VS Code与MinGw搭配使用 c_cpp_properties.json launch.json tasks.json VS Code官方文档（谷歌翻译） && 目录结构 让Msys2更顺手 glibc问题(Linux) 在VSCode中使用Git 关于学习的理念 强烈建议先初步学会使用gcc(mingw64)等命令，这样配置才不会一脸懵逼 1，下载安装

更正了顺序， 之前不知道怎么回事，内容顺序乱了 力求完美、详细，所以希望懂的人留言指点一下。 目前已经开始添加原理解释，希望大家能分享一些gcc gdb C语言等方面优秀链接 　　后续会慢慢增添内容，修正不足。 希望这篇文章能带大家入坑。 Ps.2019年消息：VSCODE已支持全局配置，C/Cpp插件也支持UI界面设置。 具体请看官网或利用搜索引擎寻找资料 请耐心看完，因为这能让你了解什么是IDE、调试、运行和命令行以及系统和程序之间的关系 如果只是想找三个文件的配置方法，请点下面导航。（其实这三个文件配置并不难，难的是没用过gcc g++ gdb，当你稍微地使用之后，配置自然是水到渠成） 基本上各平台配置内容的差异只在于那个include路径（疯狂使用搜索引擎），所以只要写下正确路径，其他就没什么大问题了 目录书签导航 下载安装（2个软件） 配置MSYS2环境 && 换源 安装Mingw-w64编译工具 变量配置 VS Code与MinGw搭配使用 c_cpp_properties.json launch.json tasks.json VS Code官方文档（谷歌翻译） && 目录结构 让Msys2更顺手 glibc问题(Linux) 在VSCode中使用Git 关于学习的理念 强烈建议先初步学会使用gcc(mingw64)等命令，这样配置才不会一脸懵逼 1，下载安装

前言 　　如题，有感于博客园最近多次翻车，感觉像胡子眉毛一把抓， 定位不了生产环境的问题。 抛开流程问题，思考在生产环境中如何做故障排除， 发现博客园里面这方面的文章比较少。 .Net 本身是提供了 sos.dll工具 帮助我们在生产中故障排除，通过提供有关内部公共语言运行时（CLR）环境的信息，帮助您在Visual Studio和Windows调试器（WinDbg.exe）中调试托管程序。 头脑风暴 故障排除的核心是： 调试待分析进程的dump文件 常规思路 ① ps aux 找到待分析进程 PID ② .netcore runtime自带createdump工具 ③ 执行 ./createdump -f -u { PId } 命令导出coredump文件，默认生成 /tmp/coredump.%d dump文件， 使用Visual Studio 或者Windebug调试dump文件 容器中遇到的障碍 .netcore app容器中需要有容器特权模式才能执行createdump命令， 否则会如下图错误 ps：可通过在docker run 生成该容器时增加 --privileged = true 操作特权 常规.netcore app容器内不包含ps命令， 难以明确容器内dotnet 进程PID 容器内导出的coredump文件，还需要使用 docker cp

【今日推荐】：为什么一到面试就懵逼！>>> 本文作者：yanxin1563 本文作者： Yunpeng-基础技术 前言 百度App从单一的搜索工具发展到今天以搜索和Feed流为双引擎的综合性内容消费服务平台，其复杂程度已然不可同日而语矣。 作为一个日活过亿的超级App，业务规模庞大，相关技术人员超过千人，客户端支持主流的移动技术，涉及近百业务方，技术形态复杂，各种组件近三百个，代码百万量级，由此带来的工程化问题是技术团队的一个极大挑战。 项目的膨胀导致了很多不起眼的小问题被无限放大，组件管理不规范、编译时间长、工程文件合并冲突、Xcode默认非彻底编译隔离等等问题，导致开发人员在开发环境上耗费了大量时间。目前业界较流行的工具对于大规模工程的支持力度相对较弱，实践起来总是有些掣肘，难以达到理想状态。 EasyBox的诞生，就是致力于为超级App量身打造一套现代、高效、优雅的研发工具链。 这篇文章的主要目的是 站在工具链的角度 上，分享一下我们在实践工程化过程中一些经验。 概述 EasyBox主体由工程组装器(Installer)、多仓库管理工具(MGit)、二进制管理工具(LFS)三部分构成，分别负责工作区的构建(组件依赖分析、工程的生成与组合)、源码仓库的管理以及二进制的管理。EasyBox架构图: 由多仓库管理工具克隆所需仓库源码，由二进制管理工具下载二进制包