这几年每年惯例的总结要新的一年开始时写写,想想过去一年做了些什么工作,同时也想想新的一年要做点什么!

其实是2017年底生活就遇到的难题,到现在仍然没有解决!不知道那天能够解决,但是内心深处的声音是继续坚持,总会有希望。其实也期望新的一年能够解决,让生活不再有羁绊。

再有两个月多一点点就整整工作五年了,前三年是学习与提高,第四年是深化,第五年是浪费!曾经有本书说第一份工作要干满五年,马上要满五年了,回头想想后两年已经没有那么大意义了。非要说后两年有什么意义,那就是多出了很多思考时间,一方面是思考工作中的问题,解决方案更加合理,问题解决也正中靶心;另外一方面是思维上的思考,其实思维上的思考是将自己拉出来,想自己的思维方式与方法,简单说就是对思考坚决问题方法的抽象,它有助于寻找问题解决方法,以最快速度给出最好方案。对于后者,虽然认识到了这一点,但是对它的思考还远未到能够应用的水平。

这一年内锻炼了问题解决的能力,让自己更加坚定地认识到,没有解决不了的问题,只有没有时间解决的问题。解决不了的问题无非两方面,一方面是时间问题,没有足够时间来解决问题,那只能搁置;另一方面是对问题没有认识清楚(当然了有一些问题就是因为没有足够时间来认识,所以无法解决),如果对问题有清晰认知,解决问题就很简单了。

新的一年了,改改毛病,继续踏实做学问!

很多知识摸底摸得差不多了,接下来是要开始分块学习了!计划列了有好多,但是真正实施的不多,接下来一年甚至两年要开始逐渐实践自己曾经的探索。计算机科学作为实践性很强的学科,很多时候说到与做到真的不是一个概念,学到与做到也不是一个概念!

希望新的一年里,能够和老婆一起克服这些工作和生活中的难题!

By Andy@2019-01-02 20:27:32

在Ubuntu的官方的Wiki中给出了Ubuntu中的应用程序崩溃的调试方法,其网址为https://wiki.ubuntu.com/DebuggingProgramCrash。这里简单翻译一下该文档,作为今后查阅资料的参考。

[TOC]

介绍

这篇文章描述了如何在Ubuntu上安装调试包,让用户可以在手动执行时提供相关信息,这些信息是发现程序错误所需的详细信息。

  1. 栈回溯监视工具-Backtrace。
  2. 内存检查工具-Valgrind,如果程序崩溃时提示“段错误”或“总线错误”。
  3. 系统调用监视工具-Strace。

    Read More

WOW64(Windows-On-Windows 64bit)是X64 Windows操作系统的一个子系统,为32位应用程序提供运行环境。类似的还有WOW32子系统,负责在32位Windows系统上运行16位应用程序。

WoW64存在的原因还要从CPU的发展上开始说,X86指令集是一个指令集架构家族,最初在Intel 8086处理器中引入,开始它主要用于16位系统。从Intel 386处理器发布开始升级为32位,并且32位指令集一直保持了很久。了解32位系统的都知道32位CPU将内存空间限制到了4G(单一用户模式进程至少是这样)。随着RAM的越来越大,4G限制就成了瓶颈,系统无法使用更大的内存空间。于是2001年Intel发布了64位的IA64架构,它是一个全新的架构,架构设计非常清晰,比老的X86架构要更好。对于软件来说兼容性很重要,但是IA64处理器无法运行X86代码,这样问题就很严重了,已有的软件无法在新的CPU上运行。于是在2003年AMD发布了AMD64架构,它是对X86架构的增量更新,用于添加64位支持。这种架构的X64处理器可以执行X86代码,所以用户可以在X64处理器上运行现有的程序和操作系统。直到今天,X86和X64依旧是个人计算机和笔记本电脑使用CPU的主流。

如下为X64和X86指令,与X86指令相对应,X64指令需要增加额外的前缀字节(REX Prefix)表示使用64位寄存器。由于指针等数据大小翻倍,所以结构体中指针偏移大小也可能会增加。

1
2
3
4
5
// X86指令
0x8B, 0x52, 0x0C, // mov edx, dword ptr [edx+0Ch]

// X64指令
0x48, 0x8B, 0x52, 0x18, // mov rdx, qword ptr [rdx+18h]

一些指令在X86和X64上编码一致,比如短跳转。区分两种指令比较通用的方法是看指令是否携带了REX前缀字节(REX前缀字节用于表示使用64位寄存器或使用64位操作数)。REX前缀字节会覆盖一部分现存X86指令,因此在执行一块代码时需要告知X64处理器按照X86还是X64来解析指令。到底是怎么告知CPU要将代码按照X86解析还是按照X64解析呢?下面看Intel的白皮书给出的关于IA-32e如何区分兼容模式和64位模式。

Read More

前面一篇总结了X86汇编中实模式的阅读笔记,这一篇总结一下保护模式的阅读笔记。

32位X86处理器

在32位处理器上,8个通用寄存器扩展为32位,段寄存器CS/SS/DS/ES扩展出描述符高速缓冲器,用于缓存保护模式下的短描述符(当然32位处理器的段寄存器 高速缓存在实模式下也是有用的,用其中的20位保存段寄存器的基地址),并且32位处理器上还多出FS/GS两个段寄存器。

32位处理器上启用了保护模式后,根据分段机制计算出来的地址值,即线性地址,这个地址在没有开启分页机制情况下就是要访问的物理地址。

32位处理器也有更灵活的内存寻址方式,除了ESP无法当作内存操作中的变址寄存器外,其他的都可以使用。如下图,在16位处理器中,只有BX/BP/SI/DI可以作为变址寻址;而在32位的处理器中,所有的通用寄存器都可以作为变址寻址的寄存器。


图1 16位处理器内存寻址方式

Read More

计算机是所有软件的基础,了解基础才能更好学习其他的内容,这里推荐一本书,李忠老师的《穿越计算机的迷雾》,它可以作为非计算机专业看的计算机原理书籍,也可以作为了解计算机发展的历史。这本书用通俗易懂的语言讲述了计算机从何而来,以及计算机最基本的原理。

再一本还是李忠老师的书,书名是《X86汇编语言-从实模式到保护模式》。它是一本讲计算机汇编语言的书籍,以NASM开源汇编器为编译工具。除了汇编语言以外,李忠老师详细讲解了实模式与保护模式,以及保护模式下的分段机制,分页机制,任务等CPU功能,这些内容的讲述为学习操作系统原理可以打下良好的基础。

这两本书都属于通俗易懂的书籍,非常推荐对计算机基础原理感兴趣而又不知从何处开始学习的人阅读。

Read More

转眼进入2018年了,去年的今天总结了前年,今年的今天总结去年。

到今天为止,庸庸碌碌的一年就正式过去了(今天为开年的第一个工作日)!之所以说庸庸碌碌是因为2017年几乎毫无成就,无论工作还是生活与学习。但是回头望望2017年,却发现它也是不可或缺的一年;虽然没有成绩,确实开始思考与探索的一年,尝试的一年。

2017年一开始就觉得自己要有自己的思考,搭建了自己独立的博客用于记录自己的思考,而这些都要是独立的思考。2017年开始阅读大部头的技术好书,不再单纯进行工作问题解决,而是问题的全面探索,锻炼自己的能力。2017年开始探索问题根源,追踪溯源到源头,并尝试逐步回溯。2017年开始慢慢学会生活,而非一贯式的工作与学习,因为生活一样重要。2017年的最后认识到读书的重要,不论技术书籍与闲书都应“博览”!

2017年的时光已逝去,适度的追忆与总结可以更好地度过以后的时间;过于沉浸于碌碌无为的2017反而会错过现在与未来的机会。

Read More

读完一本书,突然大有感悟。其实书前两天差不多已经读完,只是一直不思考,只有今天才静下心来思考了一下!

读这本书并不想评论老周如何,360如何,只是从中想到几个东西。

其实与其他公司的成功一样,基本都是偶然中的必然!腾讯只是觉得OICQ有意思,发布后又大量用户,它是个机会,所以一直坚持做。但是做着做着就找到了挣钱的门道,既不损坏用户,公司又争到了钱,也就成功了。安全卫士最初也只是老周想要为自己正名用,也并非想拿它赚多少钱,但是搞完后发现很多人用,慢慢提出了免费杀毒,并且也做到了。再到后面有了用户了,自然而然就找到了挣钱的方法,虽然比较艰苦,但是活下来不是问题。看似非有意为之,但是要准备好!

反思,书中不停强调老周有不断反思失败或挫折的习惯,也正是反思让他不断躲过了之前遇到的坑!仔细想来,自己一直“没时间”反思,总是那么忙!但是越不反思,错过的越多!以后怎么做呢?一天到晚了,晚上要反思这一天过程,争取明天过得更好!一周过去了,任务完成得如何也要反思,总结经验,下一周才能更好完成任务。一年过去了,反思这一年,才能计划明年怎么走!说到容易,做到何其难也。

Read More

windows 10在14393之后开始支持Ubuntu子系统WSL,全称Windows Subsystem for Linux(Windows的Linux子系统)。这个子系统并非Hyper-V启动Ubuntu的虚拟机,而是直接的Local系统,由子系统将Linux调用转成Native的API;这个子系统也不是简单cygwin扩展,而是比cygwin更像Linux操作系统。

之前看过老雷的文章《在调试器里看Windows 10的Linux子系统》,这里贴个链接http://geek.csdn.net/news/detail/200336,这篇文章对于Win10 RS2版本中的WSL Beta版做了分析,有兴趣可以看看这篇文章。

在Win10 RS3版本中WSL转正了,添加删除服务中没有Beta标注了,并且支持多个Linux版本。支持的Linux版本包括Ubuntu,OpenSUSE,SLES等。

这一篇简单介绍一些WSL的开启及其安装方法;在后面将微软官方博客关于WSL的原理做简单介绍。

微软的博客地址如下:

https://blogs.msdn.microsoft.com/wsl/page/2/

WSL及其上Ubuntu安装

从Win10的16215.0开始支持Ubuntu通过应用商店安装,从应用商店中搜索Ubuntu,可以看到如下的Ubuntu APP页面,直接安装即可。


图1 开启WSL可选组件

Read More

Bochs虚拟机就不过多介绍了,官网上说的非常清楚。Bochs是一款模拟形式的虚拟机,区别于VMWare等虚拟机。但是Bochs有一个内置调试器,可以用来调试系统内核,尤其调试系统内核未初始化内置调试之前的系统引导阶段代码逻辑。下面将Bochs官网的使用Bochs内置调试器的教程简单翻译一下。

原文翻译如下:

使用Bochs内置调试器

在编译Bochs时可以添加编译条件,在Bochs内部编译像GDB一样的命令行调试器,使用这个调试器可以设置断点,单步执行指令,或其他的有用的调试功能。如果有其他的调试命令你觉得对调试器非常有帮助,告诉我,我尽可能实现它。

注意:这一部分介绍了如何开启和使用Bochs命令行调试器。如果想要使用图形形式的前端请参考调试器GUI部分如何开启功能。

要是用调试器,在编译Bochs时需要使用--enable-debugger--enable-disasm编译标志进行编译配置。例如:

1
./configure --enable-debugger --enable-disasm

注意:编译时必须使用flex 2.5.4或更高版本。我听说2.5.2版本无法正常工作。

第一次启动Bochs时,会看到如下的命令行提示符。

1
bochs:1>

在命令行提示符中就可以输入如下的这些调试命令了。

Read More

前面自己总结了一下X86下的__try/__except/__finally等编译后的内容,以及异常分发到异常处理函数时的执行的过程。后面想看看X64上的内容,觉得X64的就不需要总结了,参考网上前行者的资料简单学习即可。当一点一点地看网上资料时,发现很多细节还是理解不透,无奈还是自己来总结一下。希望后来的朋友看到时不会有和我一样的感觉。后面会将参考到的资料列举一下,方便后来学习者参考,防止他们看这篇总结时也有我看他人学习笔记一样的感觉。

Visual C++支持三种异常,即C++异常处理,结构化异常处理,MFC异常。对于大多数C++程序,应该使用类型安全的C++异常处理,该处理可以确保在堆栈展开过程中调用对象析构函数;结构化异常处理为Windows提供供其自己的使用的,建议不要用于C++或MFC编程;MFC的异常不在讨论之列。其中标准C++异常处理是Visual C++上对Windows结构化异常进一步扩展,加入了展开中的对象析构等内容,所以这里也不会去总结标准C++的异常机制。

有前面的X86上的异常处理总结,这一篇总结起来就会相对简单一点。使用和上次相同的seh程序来解析(程序源码这里就不给出了)。与X86上类似的过程,在X64上也是一样,异常分发由RtlDispatchException函数负责,依次遍历“异常链表”,调用其过滤函数;如果过滤函数返回了EXCEPTION_EXECUTE_HANDLER则表示当前的异常处理函数负责处理该异常,然后进行全局展开、局部展开,最后调用异常处理函数,完成这一系列动作之后,程序恢复正常执行,执行__try*块(整个异常块)之后的代码;如果过滤函数返回继续执行即EXCEPTION_CONTINUE_EXECUTION,则返回异常出继续执行;如果返回EXCEPTION_CONTINUE_SEARCH,则继续遍历“异常链表”。当然没有处理异常最终会执行到线程起始处的异常处理函数,结果就是结束线程或进程。

Read More