Writing a Linux Debugger Part 2: Breakpoints | Hacker News Reader

Writing a Linux Debugger Part 2: Breakpoints

blog.tartanllama.xyz

142 pointsadamnemecek15 comments

Why are function trailing return types being used for simple data member access?

    auto is_enabled() const -> bool { return m_enabled; }

Please write this instead

    bool is_enabled() const  { return m_enabled; }

There is nothing to gain by writing function trailing return types in this case.

Leave them to complex lambdas declarations or template meta-programming.

Does this work?

  auto is_enabled() const { return m_enabled; }

Yes it does, assuming you are already on C++14 compiler.

On personal note, I don't think it is really worthwhile to use auto there.

I think that's a matter of taste though, isn't it? Personally I find that putting the return type on the right to be a lot more intuitive.

Does anyone know of an easy way to interact with performance monitor counters in Linux? I've been reading stuff by Brendan Gregg about DTrace and the importance of PMCs, and it made it sound like Linux doesn't have the equivalent.

There are multiple tools, and that's all Brendan Gregg has been talking about for years. Read any non-ancient posts on his blog.

VTune has a Linux client. That would be the best by far.

https://software.intel.com/en-us/intel-vtune-amplifier-xe

There's also PAPI and TAU:

http://icl.utk.edu/papi/

http://www.cs.uoregon.edu/research/tau/home.php

it's not quite there (AFAIK) yet but here's an attempt https://github.com/dtrace4linux/linux

Another nice tool is likwid. It lets you select a performance counter group (e.g. L3 CACHE) to monitor while running a program. It also provides derived metrics.

https://github.com/RRZE-HPC/likwid

Yes, this is what "perf stat <command>" does. Add more -d options to see more counters, or use -e to ask for specific counter(s) ("perf list" to list them).

I had a question the article states:

>"When the processor executes the int 3 instruction, control is passed to the breakpoint interrupt handler, which – in the case of Linux – signals the process with a SIGTRAP. You can see this process in the diagram below, where we overwrite the first byte of the mov instruction with 0xcc,"

0xCC is not 3 in decimal however it is 204. AM I missing something or is the actual number 3 obscured in the encoding somewhere?

0xCC is a special opcode for the assembly instruction "INT 3" (trigger interrupt number 3), for exactly this use case of providing an 1-byte opcode for debuggers.

The general encoding for "INT <X>" is 0xCD <X>

Thanks, that makes perfect sense, I don't know why I was thinking as a literal value. Cheers.

This is an interesting blog, I wanted to ask if any of you had any other "system specific" blogs that you read regularly and would recommend?

http://www.brendangregg.com for everything about tracing/performance measurements.

Reply on news.ycombinator.com