跳转至

tips

  • 分类于 tips
  • 需要 4 分钟阅读时间

Top

导言

原本是想写些网站建设的计划(但别人关心的只是他们搜索的内容)。所以就讲讲所在的团队吧（每个人都关心自己的下一站在哪里）

  • 分类于 tips
  • 需要 1 分钟阅读时间

Subscribe

导言

Follow学术大牛， 和阅读前沿技术博客 是科研探索的乐趣所在。

  • 分类于 tips
  • 需要 3 分钟阅读时间

Old Pintool Upgrade with newest pin

编译Old Pintool with newest pin

常见的问题：

  1. crt 相关的头文件的使用
  2. USIZE不再被定义

主要原因是头文件的include的使用不同，还有一些接口的改变。

分析基于inscount0.so的simple test pintool的make流程

$ make obj-intel64/inscount0.so
g++ 
# Warning Options
-Wall -Werror -Wno-unknown-pragmas -Wno-dangling-pointer 
# Program Instrumentation Options
-fno-stack-protector
# Code-Gen-Options
-fno-exceptions -funwind-tables -fasynchronous-unwind-tables -fPIC
# C++ Dialect
-fabi-version=2 -faligned-new -fno-rtti
# define
-DPIN_CRT=1 -DTARGET_IA32E -DHOST_IA32E -DTARGET_LINUX 
# include
-I../../../source/include/pin 
-I../../../source/include/pin/gen 
-isystem /staff/shaojiemike/Download/pin-3.28-98749-g6643ecee5-gcc-linux/extras/cxx/include 
-isystem /staff/shaojiemike/Download/pin-3.28-98749-g6643ecee5-gcc-linux/extras/crt/include 
-isystem /staff/shaojiemike/Download/pin-3.28-98749-g6643ecee5-gcc-linux/extras/crt/include/arch-x86_64 
-isystem /staff/shaojiemike/Download/pin-3.28-98749-g6643ecee5-gcc-linux/extras/crt/include/kernel/uapi 
-isystem /staff/shaojiemike/Download/pin-3.28-98749-g6643ecee5-gcc-linux/extras/crt/include/kernel/uapi/asm-x86 
-I../../../extras/components/include 
-I../../../extras/xed-intel64/include/xed 
-I../../../source/tools/Utils 
-I../../../source/tools/InstLib 
# Optimization Options
-O3 -fomit-frame-pointer -fno-strict-aliasing 
-c -o obj-intel64/inscount0.o inscount0.cpp

g++ -shared -Wl,--hash-style=sysv ../../../intel64/runtime/pincrt/crtbeginS.o -Wl,-Bsymbolic -Wl,--version-script=../../../source/include/pin/pintool.ver -fabi-version=2  
 -o obj-intel64/inscount0.so obj-intel64/inscount0.o
  -L../../../intel64/runtime/pincrt 
  -L../../../intel64/lib 
  -L../../../intel64/lib-ext 
  -L../../../extras/xed-intel64/lib 
  -lpin -lxed ../../../intel64/runtime/pincrt/crtendS.o -lpindwarf -ldl-dynamic -nostdlib -lc++ -lc++abi -lm-dynamic -lc-dynamic -lunwind-dynamic

对应的makefile规则在source/tools/Config/makefile.default.rules

# Build the intermediate object file.
$(OBJDIR)%$(OBJ_SUFFIX): %.cpp
    $(CXX) $(TOOL_CXXFLAGS) $(COMP_OBJ)$@ $<
# Build the tool as a dll (shared object).
$(OBJDIR)%$(PINTOOL_SUFFIX): $(OBJDIR)%$(OBJ_SUFFIX)
    $(LINKER) $(TOOL_LDFLAGS) $(LINK_EXE)$@ $< $(TOOL_LPATHS) $(TOOL_LIBS)
  1. how to solve the UINT64 undefined bug: inscount0.cpp include pin.H which includes types_foundation.PH

与基于 scons的编译流程的对比

由于old pintool 基于 pin2.14。作为对比也分析inscount0.so的编译过程

g++ 
# Warning Options
-Wall -Werror -Wno-unknown-pragmas
# Program Instrumentation Options
-fno-stack-protector
# Code-Gen-Options
-fPIC
# define
-DBIGARRAY_MULTIPLIER=1 -DTARGET_IA32E -DHOST_IA32E -DTARGET_LINUX 
-I../../../source/include/pin 
-I../../../source/include/pin/gen 
-I../../../extras/components/include 
-I../../../extras/xed-intel64/include 
-I../../../source/tools/InstLib 
# Optimization Options
-O3 -fomit-frame-pointer -fno-strict-aliasing  
-c -o obj-intel64/inscount0.o inscount0.cpp

同时multipim 的scons的编译细节如下,去除与pin无关的参数：

g++
# Warning Options
-Wall -Wno-unknown-pragmas 
# c++ language
-std=c++0x 
# Code-Gen-Options
 -fPIC 
# debug
 -g  
# Program Instrumentation Options
 -fno-stack-protector 
# Preprocessor Options ???TODO:
 -MMD 
# machine-dependent 
-march=core2 
# C++ Dialect
-D_GLIBCXX_USE_CXX11_ABI=0 
-fabi-version=2 
# define 
-DBIGARRAY_MULTIPLIER=1 -DUSING_XED 
-DTARGET_IA32E -DHOST_IA32E -DTARGET_LINUX 
-DPIN_PATH="/staff/shaojiemike/github/MultiPIM_icarus0/pin/intel64/bin/pinbin" -DZSIM_PATH="/staff/shaojiemike/github/MultiPIM_icarus0/build/opt/libzsim.so" -DMT_SAFE_LOG 
-Ipin/extras/xed-intel64/include 
-Ipin/source/include/pin 
-Ipin/source/include/pin/gen 
-Ipin/extras/components/include 
# Optimization Options
-O3 -funroll-loops -fomit-frame-pointer 
-c -o build/opt/simple_core.os build/opt/simple_core.cpp

STEP1: update define and include path order

对比后，pin3.28 相对 pin2.14 编译时,

  • 加入了新定义 -DPIN_CRT=1
  • include path and order changed a lot
  • 编译选项也有改变(low influence)

STEP2: code change for include

// pin/extras/crt/include/freebsd/3rd-party/include/elf.h
> typedef uint16_t Elf32_Section;
> typedef uint16_t Elf64_Section;
// /usr/include/wordexp.h
remove __THROW

STEP3: ld errors

First apply the two change to old pintool

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

上面回答部分来自ChatGPT-3.5，没有进行正确性的交叉校验。

无

  • 分类于 tips
  • 需要 6 分钟阅读时间

Intel Pin

简介

Pin 是一个动态二进制插桩工具：

  • 支持 Linux， macOS 和 Windows 操作系统以及可执行程序。
  • Pin可以通过pintools在程序运行期间动态地向可执行文件的任意位置插入任意代码（C/C++），也可以attach到一个正在运行的进程。
  • Pin 提供了丰富的API，可以抽象出底层指令集特性，并允许将进程的寄存器数据等的上下文信息作为参数传递给注入的代码。Pin会自动存储和重置被注入代码覆盖的寄存器，以恢复程序的继续运行。对符号和调试信息也可以设置访问权限。
  • Pin内置了大量的样例插桩工具的源码，包括基本块分析器、缓存模拟器、指令跟踪生成器等，根据自己的实际需求进行自定义开发也十分方便。

特点

  • 只是它的输入不是字节码，而是可执行文件的执行汇编代码(机械码)。
  • Pin 对所有实际执行的代码进行插桩，但是如果指令没有被执行过，就一定不会被插桩。
  • 工作在操作系统之上，所以只能捕获用户级别的指令。
  • 由于Pintool的编译十分自由，Pin不打算提供多线程插桩的支持。
  • 同时有3个程序运行：应用程序本身、Pin、Pintool。
  • 应用程序是被插桩的对象、Pintool包含了如何插桩的规则(用户通过API编写的插入位置和内容)
  • 三者共享同一个地址空间，但不共享库，避免了冲突。 Pintool 可以访问可执行文件的全部数据，还会与可执行文件共享 fd 和其他进程信息。

pin

基本原理

Pin机制类似Just-In-Time (JIT) 编译器，Trace插桩的基本流程（以动态基本块BBLs为分析单位）：

  • Pin 会拦截可执行文件的第一条指令，然后对从该指令开始的后续的指令序列重新“compile”新的代码，并执行
  • Pin 在分支退出代码序列时重新获得控制权限，基于分支生成更多的代码，然后继续运行。

动态基本块BBLs

通过一个例子来说明动态基本块BBLs与 汇编代码的BB的区别

switch(i)
{
    case 4: total++;
    case 3: total++;
    case 2: total++;
    case 1: total++;
    case 0:
    default: break;
}

上述代码会编译成下面的汇编, 对于实际执行时跳转从.L7进入的情况，BBLs包括四条指令，但是BB只会包括一条。

.L7:
        addl    $1, -4(%ebp)
.L6:
        addl    $1, -4(%ebp)
.L5:
        addl    $1, -4(%ebp)
.L4:
        addl    $1, -4(%ebp)

Pin会将cpuid, popf and REP prefixed 指令在执行break 成很多BBLs，导致执行的基本块比预想的要多。（主要原因是这些指令有隐式循环，所以Pin会将其拆分成多个BBLs）

Download

  1. Download the kit from Intel website
  2. Because the compatibility problem may you should install pin with archlinux package

Installation

This part is always needed by pintool, for example Zsim, Sniper.

When you meet the following situation, you should consider update your pin version even you can ignore this warning by use flags like -ifeellucky under high compatibility risk.

shaojiemike@snode6 ~/github/ramulator-pim/zsim-ramulator/pin  [08:05:47]
> ./pin
E: 5.4 is not a supported linux release

because this will easily lead to the problem

Pin app terminated abnormally due to signal 6. # or signal 4.

Install pintool(zsim) by reconfig pin version

  1. My first idea is try a compatible pin version (passd a simple test pintool, whatever) instead of the old pin.
  2. Find the suitable simpler pintool can reproduce the situation (old pin failed, but newest pin is passed)
    1. TODO: build(fix pin2.14 CXX_ABI compatibility bug), test suitability
  3. debug the pin tool in details (See in another blog)

插桩粒度

  • Trace instrumentation mode：以动态基本块BBLs为分析单位
  • Instruction instrumentation mode：以指令为分析单位
  • 其余粒度/角度，这些模式通过“缓存”插装请求来实现，因此会产生空间开销，这些模式也被称为预先插装。
  • Image instrumentation mode: 通过前提知道需要执行的所有代码，能绘制出全局的插桩情况图
  • Routine instrumentation mode: 理解为函数级插桩，可以对目标程序所调用的函数进行遍历，并在每一个routine中对instruction做更细粒度的遍历。
  • 两者都是在IMG加载时提前插桩，所有不一定routine会被执行。

范围image, section, routine, trace, basic block, instruction的含义和运行时关系

  • image包含section，section包含routine(理由：SEC_Img()，RTN_Sec()，后面的静态遍历IMG中指令条数的代码也能说明)
  • routine指的是程序中的函数或子程序，trace指的是程序执行过程中的一条路径，basic block指的是一段连续的指令序列，其中没有跳转指令，instruction指的是程序中的一条指令。
  • 在程序执行时，一个routine可以包含多个trace，一个trace可以包含多个basic block，一个basic block可以包含多个instruction。
for (SEC sec = IMG_SecHead(img); SEC_Valid(sec); sec = SEC_Next(sec))
{
    for (RTN rtn = SEC_RtnHead(sec); RTN_Valid(rtn); rtn = RTN_Next(rtn))
    {
        // Prepare for processing of RTN, an  RTN is not broken up into BBLs,
        // it is merely a sequence of INSs
        RTN_Open(rtn);

        for (INS ins = RTN_InsHead(rtn); INS_Valid(ins); ins = INS_Next(ins))
        {
            count++;
        }

        // to preserve space, release data associated with RTN after we have processed it
        RTN_Close(rtn);
    }
}

API

最重要的是

  • 插桩机制（instrumentation code）：插入位置，在什么位置插入什么样的代码
  • 分析代码（analysis code）：插入内容，在插桩点执行的代码 (和上一点的区别是什么？？？)

插桩机制（instrumentation code）

  • TRACE_AddInstrumentFunction Add a function used to instrument at trace granularity
  • BBL粒度插桩相关API
  • INS_AddInstrumentFunction() Add a function used to instrument at instruction granularity
  • 指令粒度插桩相关API
  • IMG_AddInstrumentFunction() Use this to register a call back to catch the loading of an image
  • 插桩不仅可以对每个指令插桩，还可以通过分类筛选后，只对符合要求的指令进行插桩
  • 比如，使用INS_InsertPredicatedCall()

遍历所有的指令

// Forward pass over all instructions in bbl
for( INS ins= BBL_InsHead(bbl); INS_Valid(ins); ins = INS_Next(ins) )

// Forward pass over all instructions in routine
for( INS ins= RTN_InsHead(rtn); INS_Valid(ins); ins = INS_Next(ins) )

遍历trace内BBLs

// Visit every basic block  in the trace
for (BBL bbl = TRACE_BblHead(trace); BBL_Valid(bbl); bbl = BBL_Next(bbl))
{
    // Insert a call to docount before every bbl, passing the number of instructions
    BBL_InsertCall(bbl, IPOINT_BEFORE, (AFUNPTR)docount, IARG_UINT32, BBL_NumIns(bbl), IARG_END);
}

遍历指令里的memOperands

UINT32 memOperands = INS_MemoryOperandCount(ins);

// Iterate over each memory operand of the instruction.
for (UINT32 memOp = 0; memOp < memOperands; memOp++){
    if (INS_MemoryOperandIsRead(ins, memOp)||INS_MemoryOperandIsWritten(ins, memOp)
        //xxx
}

Pintool

最重要的是

  • 插桩机制（instrumentation code）：插入位置，在什么位置插入什么样的代码
  • 分析代码（analysis code）：插入内容，在插桩点执行的代码 (和上一点的区别是什么？？？)

Pintool代码

示例分析

// IPOINT_BEFORE 时运行的分析函数
VOID printip(VOID* ip) { fprintf(trace, "%p\n", ip); }

// Pin calls this function every time a new instruction is encountered
VOID InstructionFuc(INS ins, VOID* v)
{
    // Insert a call to printip before every instruction, and pass it the IP
    // IARG_INST_PTR：指令地址 一类的全局变量？？？
    INS_InsertCall(ins, IPOINT_BEFORE, (AFUNPTR)printip, IARG_INST_PTR, IARG_END);
}

int main(int argc, char* argv[])
{
    // Initialize pin
    if (PIN_Init(argc, argv)) return Usage();

    // 登记InstructionFuc为以指令粒度插桩时每条指令触发的函数
    INS_AddInstrumentFunction(InstructionFuc, 0);

    // 登记PrintFuc为程序结束时触发的函数
    PIN_AddFiniFunction(PrintFuc, 0);

    // 部署好触发机制后开始运行程序
    PIN_StartProgram();

    return 0;
}

Debug pintool

目标：以样例插桩工具的源码为对象，熟悉pin的debug流程。

以官方教程为例子：

uname -a #intel64
cd source/tools/ManualExamples
# source/tools/Config/makefile.config list all make option
make all OPT=-O0 DEBUG=1 TARGET=intel64 |tee make.log|my_hl
# or just select one: make obj-intel64/inscount0.so
# $(OBJDIR)%$(PINTOOL_SUFFIX) - Default rule for building tools.
#    Example: make obj-intel64/mytool.so

测试运行

../../../pin -t obj-intel64/inscount0.so -- ./a.out #正常统计指令数 to inscount.out

下面介绍Pin 提供的debug工具：

首先创建所需的-g的stack-debugger.so和应用fibonacci.exe

cd source/tools/ManualExamples
make OPT=-O0 DEBUG=1 stack-debugger.test

其中OPT=-O0选项来自官方文档Using Fast Call Linkages小节，说明需要OPT=-O0选项来屏蔽makefile中的-fomit-frame-pointer选项，使得GDB能正常显示stack trace(函数堆栈？)

Debug application in Pin JIT mode

$ ../../../pin -appdebug -t obj-intel64/stack-debugger.so -- obj-intel64/fibonacci.exe 1000
Application stopped until continued from debugger.
Start GDB, then issue this command at the prompt:
  target remote :33030

使用pin的-appdebug选项，在程序第一条指令前暂停，并启动debugger窗口。在另一个窗口里gdb通过pid连接:

$ gdb fibonacci #如果没指定应用obj-intel64/fibonacci.exe
(gdb) target remote :33030 #连接gdb端口
(gdb) file obj-intel64/fibonacci.exe #如果没指定应用, 需要指定程序来加载symbols
(gdb) b main #continue 等正常操作

Pintool添加自定义debug指令

能够在上一小节的debug窗口里，通过自定义debug指令打印自定义程序相关信息(比如当前stack使用大小)

Pintool设置满足条件时break并启动debug窗口

Pintool “stack-debugger” 能够监控每条分配stack空间的指令，并当stack使用达到阈值时stop at a breakpoint。

这功能由两部分代码实现，一个是插桩代码，一个是分析代码。

static VOID Instruction(INS ins, VOID *)
{
    if (!EnableInstrumentation) // ROI(Region of interest)开始插桩测量
        return;

    if (INS_RegWContain(ins, REG_STACK_PTR)) //判断指令是不是会改变stack指针(allocate stack)
    {
        IPOINT where = IPOINT_AFTER;
        if (!INS_IsValidForIpointAfter(ins))
            where = IPOINT_TAKEN_BRANCH; //寻找stack空间判断函数插入位置(指令执行完的位置)。如果不是after, 就是taken branch

        INS_InsertIfCall(ins, where, (AFUNPTR)OnStackChangeIf, IARG_REG_VALUE, REG_STACK_PTR,
            IARG_REG_VALUE, RegTinfo, IARG_END); // 插入OnStackChangeIf函数，如果OnStackChangeIf()返回non-zero, 执行下面的DoBreakpoint函数
        INS_InsertThenCall(ins, where, (AFUNPTR)DoBreakpoint, IARG_CONST_CONTEXT, IARG_THREAD_ID, IARG_END);
    }
}

所需的两个函数的分析代码如下：

static ADDRINT OnStackChangeIf(ADDRINT sp, ADDRINT addrInfo)
{
    TINFO *tinfo = reinterpret_cast<TINFO *>(addrInfo);

    // The stack pointer may go above the base slightly.  (For example, the application's dynamic
    // loader does this briefly during start-up.)
    //
    if (sp > tinfo->_stackBase)
        return 0;

    // Keep track of the maximum stack usage.
    //
    size_t size = tinfo->_stackBase - sp;
    if (size > tinfo->_max) 
        tinfo->_max = size; //更新stack使用大小

    // See if we need to trigger a breakpoint.
    //
    if (BreakOnNewMax && size > tinfo->_maxReported)
        return 1;
    if (BreakOnSize && size >= BreakOnSize)
        return 1;
    return 0;
}

static VOID DoBreakpoint(const CONTEXT *ctxt, THREADID tid)
{
    TINFO *tinfo = reinterpret_cast<TINFO *>(PIN_GetContextReg(ctxt, RegTinfo));

    // Keep track of the maximum reported stack usage for "stackbreak newmax".
    //
    size_t size = tinfo->_stackBase - PIN_GetContextReg(ctxt, REG_STACK_PTR);
    if (size > tinfo->_maxReported)
        tinfo->_maxReported = size;

    ConnectDebugger();  // Ask the user to connect a debugger, if it is not already connected.

    // Construct a string that the debugger will print when it stops.  If a debugger is
    // not connected, no breakpoint is triggered and execution resumes immediately.
    //
    tinfo->_os.str("");
    tinfo->_os << "Thread " << std::dec << tid << " uses " << size << " bytes of stack.";
    PIN_ApplicationBreakpoint(ctxt, tid, FALSE, tinfo->_os.str());
}

OnStackChangeIf函数监控当前的stack使用并判断是否到达阈值。DoBreakpoint函数连接debugger窗口，然后触发breakpoint，并打印相关信息。

也可以使用-appdebug_enable参数，取消在第一条指令前开启GDB窗口的功能，而是在触发如上代码的break时，才开启GDB窗口的连接。

而上述代码中的ConnectDebugger函数实现如下：

static void ConnectDebugger()
{
    if (PIN_GetDebugStatus() != DEBUG_STATUS_UNCONNECTED) //判断是不是已有debugger连接
        return;

    DEBUG_CONNECTION_INFO info;
    if (!PIN_GetDebugConnectionInfo(&info) || info._type != DEBUG_CONNECTION_TYPE_TCP_SERVER) //PIN_GetDebugConnectionInfo()获取GDB所需的tcp连接端口
        return;

    *Output << "Triggered stack-limit breakpoint.\n";
    *Output << "Start GDB and enter this command:\n";
    *Output << "  target remote :" << std::dec << info._tcpServer._tcpPort << "\n";
    *Output << std::flush;

    if (PIN_WaitForDebuggerToConnect(1000*KnobTimeout.Value())) //等待其余GDB窗口的连接
        return;

    *Output << "No debugger attached after " << KnobTimeout.Value() << " seconds.\n";
    *Output << "Resuming application without stopping.\n";
    *Output << std::flush;
}

Tips for Debugging a Pintool

这部分讲述了如何debug Pintool中的问题。（对Pintool的原理也能更了解

为此，pin使用了-pause_tool n 暂停n秒等待gdb连接。

../../../pin -pause_tool 10 -t /staff/shaojiemike/github/sniper_PIMProf/pin_kit/source/tools/ManualExamples/obj-intel64/stack-debugger.so -- obj-intel64/fibonacci.exe 1000
Pausing for 10 seconds to attach to process with pid 3502000
To load the debug info to gdb use:
*****************************************************************
set sysroot /not/existing/dir
file
add-symbol-file /staff/shaojiemike/github/sniper_PIMProf/pin_kit/source/tools/ManualExamples/obj-intel64/stack-debugger.so 0x7f3105f24170 -s .data 0x7f31061288a0 -s .bss 0x7f3106129280
*****************************************************************

注意gdb对象既不是pin也不是stack-debugger.so,而是intel64/bin/pinbin。原因是intel64/bin/pinbin是pin执行时的核心程序，通过htop监控可以看出。

# shaojiemike @ snode6 in ~/github/sniper_PIMProf/pin_kit/source/tools/ManualExamples on git:dev x [19:57:26]
$ gdb ../../../intel64/bin/pinbin 
(gdb) attach 3502000

这时GDB缺少了stack-debugger.so的调试信息，需要手动添加。这里的add-symbol-file命令是在pin启动时打印出来的，直接复制粘贴即可。

(gdb) add-symbol-file /staff/shaojiemike/github/sniper_PIMProf/pin_kit/source/tools/ManualExamples/obj-intel64/stack-debugger.so 0x7f3105f24170 -s .data 0x7f31061288a0 -s .bss 0x7f3106129280
(gdb) b main #或者 b stack-debugger.cpp:94
gef➤  info b                                                         
Num     Type           Disp Enb Address            What                    
1       breakpoint     keep y   <MULTIPLE>                                  
1.1                         y   0x00000000000f4460 <main>          # 无法访问的地址，需要去除         
1.2                         y   0x00007f3105f36b65 in main(int, char**) at stack-debugger.cpp:94 
(gdb) del 1.1
(gdb) c

个人尝试： 使用VSCODE调试Pintool

  • 想法：VSCODE的GDB也可以attach PID，理论上是可以的
  • 实际问题：VSCODE attach pid后，不会stopAtEntry，只会在已经设置好的断点暂停。但是无法访问到stack-debugger.so的调试信息，无法设置断点。

构建Pintool

  • 首先需要熟悉API
  • PinTool 编译需要自身的 Pin CRT(C RunTime)库，这个库是 Pin 提供的，可以在 Pin 安装目录下找到。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://paper.seebug.org/1742/

https://software.intel.com/sites/landingpage/pintool/docs/98690/Pin/doc/html/index.html#APPDEBUG_UNIX

  • 分类于 tips
  • 需要 1 分钟阅读时间

URLs

导言

frequently-used out-of-work urls

  • 分类于 tips
  • 需要 5 分钟阅读时间

Git Standardization

workflow

内容模板

隐藏文件夹 .github , 里面放两个文件：

ISSUE_TEMPLATE.md

PULL_REQUEST_TEMPLATE.md

分支模型

Git Flow 分支模型

仓库有两个基础分支：

dev（默认分支）
master（用于发布）

通过pull request来合并新的代码：

协作者的代码通过pr合并到dev
dev通过pr合并到master

注意点：

merge 到 dev，使用squash merge
merge 到 master，使用普通的merge
永远不向master直接commit代码

GitHub Flow 分支模型

只有一个长期分支 master ,而且 master 分支上的代码，永远是可发布状态,

CI(Continuous Integration)集成

netlify

to do

github action

github自带的，貌似比Travis CI好用

ctest 怎么写

https://www.ruanyifeng.com/blog/2019/09/getting-started-with-github-actions.html

travis ci

Travis CI 提供的是持续集成服务（Continuous Integration，简称 CI）。它绑定 Github 上面的项目，只要有新的代码，就会自动抓取。然后，提供一个运行环境，执行测试，完成构建，还能部署到服务器。

持续集成的好处在于，每次代码的小幅变更，就能看到运行结果，从而不断累积小的变更，而不是在开发周期结束时，一下子合并一大块代码。

  1. 使用准备
  2. 登录 https://app.travis-ci.com/ ,绑定github,选择监听仓库.
  3. 项目里面有可运行的代码,项目还包含构建或测试脚本
  4. .travis.yml
  5. 在项目根目录下新建 .travis.yml 文件。参考官方文档编写 https://docs.travis-ci.com/user/languages/cpp/
  6. 运行流程
  7. install 阶段：安装依赖
  8. script 阶段：运行脚本
  9. 可选部分
before_install：install 阶段之前执行
before_script：script 阶段之前执行
after_failure：script 阶段失败时执行
after_success：script 阶段成功时执行
before_deploy：deploy 步骤之前执行
after_deploy：deploy 步骤之后执行
after_script：script 阶段之后执行
  1. 运行状态
passed：运行成功，所有步骤的退出码都是0
canceled：用户取消执行
errored：before_install、install、before_script有非零退出码，运行会立即停止
failed ：script有非零状态码 ，会继续运行
  1. 可选加密环境变量

git commit 规范

Angular规范

<type>(<scope>): <subject>

type 必须

name description
feat： 新功能（feature）。
fix/to： 修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
fix： 产生diff并自动修复此问题。适合于一次提交直接修复问题
to： 只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
docs： 文档（documentation）。
style： 格式（不影响代码运行的变动）。
refactor： 重构（即不是新增功能，也不是修改bug的代码变动）。
perf： 优化相关，比如提升性能、体验。
test： 增加测试。
chore： 构建过程或辅助工具的变动。
revert： 回滚到上一个版本。
merge： 代码合并。
sync： 同步主线或分支的Bug。

规范化commit message

格式为：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  1. 对于Revert： If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

  2. type的类型有：

  3. feat: A new feature

  4. fix: A bug fix
  5. docs: Documentation only changes
  6. style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)空白、格式、缺少分号等
  7. refactor:(重构) A code change that neither fixes a bug nor adds a feature
  8. perf: A code change that improves performance
  9. test: Adding missing or correcting existing tests

  10. chore: (琐事)Changes to the build process or auxiliary tools（辅助工具） and libraries such as documentation generation

  11. scope: commit 改变的位置，如果是多处写*

  12. subject: 简明的描述：
  13. 使用祈使句，现在时态
  14. 不要.结尾
  15. 第一个字母不要大写
  16. body: 包括改变的动机，并将其与以前的行为进行对比。
  17. footer: Breaking Changes或者reference GitHub issues that this commit closes. Breaking Changes should start with the wordBREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

自动生成Release Notes

规范化commit

插件 vscode插件git-commit-plugin

命令行 husky + commitlint

工具

  1. Standard Version
  2. 实现自动化版本控制,自动创建changelog, 创建 git tags
  3. 安装
npm cache clean --force #npm指令清除npm缓存
# 删除node_module包
npm install -g npm # npm 更新到最新
npm install -g n
n latest # node 更新
   Note: the node command changed location and the old location may be remembered in your current shell.
            old : /usr/bin/node
            new : /usr/local/bin/node
   To reset the command location hash either start a new shell, or execute PATH=$PATH"
PATH=/usr/local/bin/:$PATH
npm install -D standard-version
  1. 编写package.json
"scripts": {
   "release": "standard-version"
}

  1. CHANGELOG.md 记录内容的配置

    1. 创建.versionrc
    {
"types": [
   {"type": "chore", "section":"Others", "hidden": false},
   {"type": "revert", "section":"Reverts", "hidden": false},
   {"type": "feat", "section": "Features", "hidden": false},
   {"type": "fix", "section": "Bug Fixes", "hidden": false},
   {"type": "improvement", "section": "Feature Improvements", "hidden": false},
   {"type": "docs", "section":"Docs", "hidden": false},
   {"type": "style", "section":"Styling", "hidden": false},
   {"type": "refactor", "section":"Code Refactoring", "hidden": false},
   {"type": "perf", "section":"Performance Improvements", "hidden": false},
   {"type": "test", "section":"Tests", "hidden": false},
   {"type": "build", "section":"Build System", "hidden": false},
   {"type": "ci", "section":"CI", "hidden":false}
]
}

  2. 使用Standard Version

// 初次发布版本
npm run release --first-release
npm run release #(自动更新版本号，自动更新 CHANGELOG.md, 自动创建 git tag)
git push --follow-tags origin master
  1. 寄
  2. Commitizen for contributors
  3. Linux下commit规范辅助，用来选择(没vscode的时候用)
  4. 用 git-cz 来提交文件
  5. https://www.jianshu.com/p/acfdd4ca0104
  6. Visual Studio Code Commitizen Support vscode的插件
  7. conventional-changelog/commitlint 阻止不规范的提交

github-release-notes

github-release-notes，以下简称 gren ，是用来一键向 github 发布 release notes 的工具。 https://zhuanlan.zhihu.com/p/99499246

https://blog.csdn.net/weixin_39586683/article/details/110643111

release 语义化版本 semver

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

Git auto-release requirements

  1. github Actions / travis-ci
  2. 自动化测试
  3. Commitizen / Visual Studio Code Commitizen Support
  4. 规范commit message
  5. standard-version
  6. 更新 package 版本并打 tag
  7. github-release-notes
  8. 生成 release-log

需要进一步的研究学习

写个github模板

  1. 明确文件结构
  2. src/include/build/Doc/Debug/test/example
  3. 清晰的README
  4. Intro/Install&Run/Features/Bugs/Acknowledge
  5. 图片和标签
    1. https://shields.io/category/build
  6. Release的自动发布
  7. 规范commit
  8. 其他自动化的轮子持续整合 (Continuous Integration, CI)
  9. travis ci
  10. github action
    1. ctest 怎么写？
  11. cmake.yml
  12. .github/workflow
    1. https://github.com/iBug/AWS-Lambda-webhook-py/tree/master/.github/workflows
    2. https://github.com/Kirrito-k423/github-stats
  13. 文档生成
    1. doxygen
    2. Doxygen主要解决说明书问题，可以在我们写代码的时候讲注释转化为说明书，Graphviz主要是用于图形展示
    3. 有项目，文件，函数三部分的书写要求 https://www.cnblogs.com/silencehuan/p/11169084.html
  14. Codecov
    1. 代码覆盖率，执行部分占比。因为未执行部分可能是错的
  15. projects/ bug fixs
  16. 设置为 template repository
  17. 查看 https://app.travis-ci.com/github/Kirrito-k423/githubTemplate

plus

将网站变成带名字的md格式参考文献的插件

Boost 设置

set(Boost_USE_STATIC_LIBS ON)

set(Boost_DEBUG ON)

Boost_INCLUDE_DIR: 含有boost头文件的目录 Boost_LIBRARYDIR: 偏好的含有boost库的库目录

https://stackoverflow.com/questions/3897839/how-to-link-c-program-with-boost-using-cmake

Boost Install

http://c.biancheng.net/view/7772.html cache?

cmake boost install path

https://cloud.tencent.com/developer/ask/107360

设置boost-root 查看安装位置

Travis-CI Install

Travis-CI 依赖软件包每次都要重新安装吗

apt-get install in a GitHub Actions workflow

https://stackoverflow.com/questions/57982945/how-to-apt-get-install-in-a-github-actions-workflow

Actions may have no Boost, where

ctest

Ctest add build/bin to test

Ctest https://www.cnblogs.com/hustcpp/p/12922998.html

https://blog.csdn.net/zcteo/article/details/117527823?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EOPENSEARCH%7Edefault-15.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EOPENSEARCH%7Edefault-15.no_search_link

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

还是ipcc的github组织的太烂了，需要学习一下

参考文献

https://zhuanlan.zhihu.com/p/67620599

http://www.ruanyifeng.com/blog/2017/12/travis_ci_tutorial.html

https://github.com/levy9527/blog/issues/1

  • 分类于 tips
  • 需要 3 分钟阅读时间

Conference

论文索引网站

Mendeley，

ResearchGate

Web of Science

PubMed生物

Nature Index

dblp computer science bibliography，按照会议搜索.DBLP默认是以年份和会议名称排序的

Google Scholar

Microsoft Academic。最近，微软宣布将关闭仅次于谷歌Scholar的第二大学术搜索引擎Microsoft Academic

相关论文的查找

查找相关论文的引用关系，并可视化

论文会议查找

  1. 在 Google Scholar 或者IEEE Xplore和 dblp里输入论文名，在所有版本里选择最新的(一般就是论文发出的会议和期刊)
  2. 获取论文会议名后
  3. 在CCF推荐会议里查找（不要缩写，查找关键字）

期刊查询

LetPub

期刊查询小助手

翻译

DeepL全文翻译

影响因子

影响因子(impact factor，IF)是ISl的期刊引证报告(Journal Citation Reports，JCR)中公布的一项数据，自1975年开始，JCR每年公布一次上一年的数据。影响因子指某期刊前两年发表的论文在统计当年的被引用总次数除以该期刊在前两年内发表的论文总数。这是一个国际上通用的期刊评价指标。影响因子是以年为单位进行计算的。

期刊影响因子

https://academic-accelerator.com/

https://www.scimagojr.com/journalsearch.php?q=20571&tip=sid

综合

CCF 推荐会议下载 https://www.ccf.org.cn/Focus/2019-04-25/663625.shtml

https://blog.csdn.net/tmb8z9vdm66wh68vx1/article/details/100571714

https://github.com/bugaosuni59/TH-CPL

HPC期刊，会议时间

CCF会议deadline可视化

https://ccfddl.github.io/

call4papers

A类期刊

名称 全称 截稿时间 结果时间 篇幅 官网
A类期刊
TOCS ACM Transactions on Computer Systems - - - https://dl.acm.org/journal/tocs
TPDS IEEE Transactions on Parallel and Distributed Systems - - - -
TC IEEE Transactions on Computers - - - -
TCAD IEEE Transactions On Computer-Aided Design Of Integrated Circults And Systems - - - -
TOS ACM Transactions on Storage - - - -
综合类A类期刊
JACM Journal of the ACM - - - -
Proc. IEEE Proceedings of the IEEE - - - -
- Science China - - - -
- 中国科学 - - - -

A类会议

名称 全称 上次时间 下次时间 篇幅 官网
FAST USENIX Conference on File and Storage Technologies 2022-2-22～24 2023-2-20～23 长文11页，短文6页 https://www.usenix.org/conference/fast22/technical-sessions
FPGA ACM/SIGDA International Symposium on Field-Programmable Gate Arrays 2022-2-27~3-1 online - - https://www.isfpga.org
ASPLOS International Conference on Archltectural Support for Programming Languages and Operating Systems 2022-02-28～3-4 2023-2 - https://asplos-conference.org/2022/
PPoPP ACM SIGPLAN Symposium on Principles & Practice Of Parallel Programming 22-4-2~6 online https://ppopp22.sigplan.org
HPCA International Symposium on High-Performance Computer Architecture 2022-4-2～6 线上 - https://hpca-conf.org/2022/
EuroSys European Conference on Computer Systems 2022-4-5～8 法国 12页正文 https://2022.eurosys.org
SIGMETRICS International Conference on Measurement and Modeling Of Computer Systems（计算机性能建模、分析与优化领域的顶级会议） 2022-6-6～10 india 12页正文 https://www.sigmetrics.org/index.shtml
ISCA International Symposium on Computer Architecture 21-6-14～19 22-6-11～15 - https://www.iscaconf.org/isca2021/program/
DAC Design Automation Conference 22-7-10~14 USA - https://www.dac.com
USENIX ATC USENIX Annul Technical Conference 2022-7-11~13 USA 长文11页，短文5页 https://www.usenix.org/conference/atc22
MICRO IEEE/ACM International Symposium on Microarchitecture 2021-10-18~22 online 2022-10 USA - https://www.microarch.org/micro55/
SC International Conference for High Performance Computing, Networking, Storage, and Analysis 2022-11-12~13 USA - https://sc22.supercomputing.org
综合或者交叉学科类A类会议
RECOMB International Conference on Research in Computational Molecular Biology 2019-11-01 - - -
ISMB International conference on Intelligent Systems for Molecular Biology 2020-01-30 - - -
WWW International World Wide Web Conferences 2019-10-14 2020-1-10 长文12页，短文6页 https://www2020.thewebconf.org/
EC ACM Conference on Economics and Computation - - - -

ASPLOS - 计算机系统领域顶级会议

Architectural Support for Programming Languages and Operating Systems (ASPLOS)

ASPLOS（编程语言和操作系统的体系结构支持会议）是ACM开办的一个以体系结构为核心内容的多学科会议，其研究领域跨越硬件、体系结构、编译器、编程语言、操作系统、网络和应用，尤其关注这些学科间的交叉性研究课题。

ASPLOS的开会年份非常奇怪，82、87、89、91、92、94、96、98、00、02、04、06、08、09，既不是双年会，又不是但年会，还说不准奇数年或偶数年开会，真是个“不走寻常路”的会议。但ASPLOS绝对是一个精品会议，一年仅录用20多篇论文，几乎每篇都会受到计算机领域的大量引用。

ASPLOS从创办至今推动了RISC、RAID和大规模多处理器等多项技术的发展，影响力较大。

SC

一年一度的世界超算大会（International Conference for High Performance Computing, Networking, Storage and Analysis， 简称SC) 会发布Top500

IISWC

IEEE International Symposium on Workload Characterization (IISWC)

这个会主要就是研究怎么更科学的设计、分析和评估workload，很多著名的benchmark都会在这个会上发布。

PMBS

IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS)

需要进一步的研究学习

  1. https://researchain.net/ is what？

OSDI: USENIX Operating Systems Design and Implementation (26/2=13)

SOSP: ACM SIGOPS Symp on OS Principles (25/2=13)

ASPLOS: Architectural Support for Prog Lang and OS (31)

FAST: USENIX Conference on File and Storage Technologies (23)

Usenix: Annual Usenix Technical Conference (34)

OSDI，这是一个收录范围相当广的会议。提到OSDI，就得提到排名第11的另一 个会议： SOSP。这两个是OS最好的会议，每两年开一次，轮流开，比如今年是OSDI，那么 明年就是SOSP。由于这两个会议方向很广，因此影响很大。

在Architecture领域，最好的会议是ISCA，HPCA和MICRO。

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

查询期刊 https://www.letpub.com.cn/index.php?page=journalapp

http://blog.sina.com.cn/s/blog_556a37e10100mdnc.html

https://www.zhihu.com/question/26583423

https://blog.csdn.net/chen_shiqiang/article/details/76167981

  • 分类于 tips
  • 需要 2 分钟阅读时间

HDMI

HDMI

高清多媒体界面（英语：High Definition Multimedia Interface，缩写：HDMI）是一种全数字化影像和声音发送接口，可以发送未压缩的音频及视频信号。HDMI可以同时发送音频和视频信号，由于音频和视频信号采用同一条线材，大大简化系统线路的安装难度。

与DP的区别

HDMI是被设计来取代较旧的模拟信号影音发送接口。HDMI继承DVI的核心技术“传输最小化差分信号”TMDS，从本质上来说仍然是DVI的扩展。画面是以逐行的方式被发送，并在每一行与每祯画面发送完毕后加入一个特定的空白时间（类似模拟扫描线），并没有将数据“Micro-Packet Architecture（微数据包架构）”化，也不会只更新前后两帧画面改变的部分。每张画面在该更新时都会被完整的重新发送。

而DisplayPort一开始则面向液晶显示器开发，采用“Micro-Packet Architecture(微数据包架构)”传输架构，视频内容以数据包方式传送，这一点同DVI、HDMI等视频传输技术有着明显区别。

更多先进特性对比： https://www.cnbeta.com/articles/tech/1034975.htm

历史

HDMI 1.4

2009年5月28日提出，最高支持4K×2K（3840×2160p@24 Hz/25 Hz/30 Hz或4096×2160p@24 Hz）

HDMI 2.0

2013年9月4日提出

  1. 新增2160p@50 YCbCr 4:2:0、2160p@60 YCbCr 4:2:0（4K分辨率）
  2. 传输带宽18Gbit/s 支持4096*2160*60Hz

HDMI 2.1

2017年1月4日提出

  1. 支持的最大分辨率为 10K/120 Hz

比特率编码

在早期的DP和HDMI标注中，数字信号大多使用8b/10b的比特率编码进行传输。在8b/10b编码模式下，意味着每8位数据在实际传输中需要10位的传输带宽，而这些多出来的冗余用来确保信号的完整性，这意味着他们只有80%的理论带宽可以用来传输数据。

而在最新的协议下，DP 2.0采用128b/132b进行传输，编码效率效率提升到97%，而HDMI 2.1则采用16b/18b进行传输，编码效率为88.9%。

加上同代的DP接口一般都拥有更高的传输速率，所以最新一代DP接口相对HDMI的拥有更高的数据速率。

数据表示

每个像素都拥有红色，绿色和蓝色（RGB）这三个数据点，或者使用亮度，蓝色色度差和红色色度差（YCbCr / YPbPr）三个数据点

各种接口速率

查看电脑USB接口

接口驱动更新

？？？

软件的帧率

Windows

Android

实际应用

联想2020R7000

type c，同时支持dp1.2的视频输出 21.6Gbps

HDMI2.0 18Gbps

怎么算

小米的显示器是DP1.4的接口 10bits

但是实际是8bits 下需要的带宽为为3*8*3440*1440*100Hz=11888640000bps 3种颜色每个8位。

11888640000bps / 0.8 = 14860800000bps 也不对，哪里有问题

实际

买了根DP1.4的线，但是只有DP1.2的口 但是144Hz带不动，会花屏，或者闪烁。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://zh.wikipedia.org/wiki/USB#%E6%A0%87%E5%87%86USB%E6%8E%A5%E5%8F%A3

https://www.cnbeta.com/articles/tech/1034975.htm

  • 分类于 tips
  • 需要 2 分钟阅读时间

DP

DP

DisplayPort（简称DP）是一个由PC及芯片制造商联盟开发，视频电子标准协会（VESA）标准化的数字式视频接口标准。该接口免认证、免授权金，主要用于视频源与显示器等设备的连接，并也支持音频、USB和其他形式的资料。

用于取代传统的VGA、DVI。 DisplayPort是第一个依赖数据包化资料传输技术的显示连接端口。

历史

1.0

2006年5月发布。带宽10.8Gbps。DisplayPort 1.0的最大传输速度是8.64Gbit/s，长度是2米。已经废弃。

1.2

于2009年12月22日发布。它最大的改变是传输速度增加两倍到21.6Gbit/s（High Bit Rate 2（HBR2）mode），支持4K（4096X2160）60Hz，因此支授更高的分辨率、帧速率及色深。苹果公司设计的Mini DisplayPort亦兼容此标准。支持3D、支持多流（multi-streaming）。目前此版本是主流。

1.3

2014年9月15日，视频电子标准协会发布DisplayPort 1.3，带宽速度最高32.4 Gbps（HBR3），编码后有效带宽为25.92 Gbps，可支持4K（3840X2160）120hz、5K（5120X2880）60hz、8K（7680X4320）30hz。

1.4

2016年2月份最终版的DP 1.4连接端口规范，新标准基于2014年9月的DP 1.3规范，带宽不变但加入了显示压缩流(Display Stream Compression)技术、前向错误更正(Forward Error Correction)、高动态范围数据包（HDR meta transport），声道也提升到32声道1536 KHz采样率，一般情况下，DP1.4可提供4K 120Hz 8bit输出，若搭配DSC技术，可提供4K 144Hz 10bit输出。

DP1.4目前有严重BUG，无法进入bios或屏幕休眠后无法唤醒，20和30系显卡NVIDIA官方尚未放出修复更新，必须要显卡厂商自行修复，建议改用HDMI2.1

2.0

  1. 三倍数据带宽性能 之前版本的DisplayPort v1.4a提供了32.4 Gbps的最大链路带宽，四个通道中的每一个都以8.1 Gbps / lane的链路速率运行。使用8b / 10b信道编码，相当于25.92 Gbps的最大有效载荷。

DP 2.0将最大链路速率提高到20 Gbps / lane，并具有更高效的128b / 132b信道编码，最大有效载荷为77.37 Gbps - 与DP 1.4a相比，增加了三倍。

这意味着DP 2.0是第一个以60 Hz刷新率支持8K分辨率（7680 x 4320）的标准，全彩色4：4：4分辨率，包括每像素30位（bpp），支持HDR-10。

  1. 单显示分辨率??? 一个16K（15360×8640）显示器@ 60Hz和30 bpp 4：4：4 HDR（带DSC）

    一个10K（10240×4320）显示器@ 60Hz和24 bpp 4：4：4（无压缩） 双显示分辨率

    两个8K（7680×4320）显示器@ 120Hz和30 bpp 4：4：4 HDR（带DSC）

    两个4K（3840×2160）显示@ 144Hz和24 bpp 4：4：4（无压缩） 三重显示分辨率

    三个10K（10240×4320）显示器@ 60Hz和30 bpp 4：4：4 HDR（带DSC）

    三个4K（3840×2160）显示@ 90Hz和30 bpp 4：4：4 HDR（无压缩）

特点

  1. 完全兼容现有HDMI1.4a标准和旧的HDMI标准。
  2. 支持USB Type-C。
  3. 支持144Hz刷新率
  4. 支持6、8、10、12与16位色深。
  5. 1080p的有效传输带宽保证长度为5米。
  6. 多屏幕输出 DisplayPort 1.2支持MST（Multi-Stream Transport），单个DP可连接到多个显示器。要使用这项功能，显示器需要支持DP 1.2菊花链（Daisy-chaining），或使用MST Hub把DP一个拆成三个。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

无