In my previous post, LLVM integrated assembler: Improving MCExpr and MCValue delved into enhancements made to LLVM's internal MCExpr and MCValue representations. This post covers recent refinements to MC, focusing on expression resolving and relocation generation.
LLVM integrated assembler: Improving MCExpr and MCValue
In my previous post, Relocation Generation in Assemblers, I explored some key concepts behind LLVM’s integrated assemblers. This post dives into recent improvements I’ve made to refine that system.
The LLVM integrated assembler handles fixups and relocatable
expressions as distinct entities. Relocatable expressions, in
particular, are encoded using the MCValue class, which
originally looked like this:
1 | class MCValue { |
Relocation generation in assemblers
This post explores how GNU Assembler and LLVM integrated assembler generate relocations, an important step to generate a relocatable file. Relocations identify parts of instructions or data that cannot be fully determined during assembly because they depend on the final memory layout, which is only established at link time or load time. These are essentially placeholders that will be filled in (typically with absolute addresses or PC-relative offsets) during the linking process.
Relocation generation: the basics
Symbol references are the primary candidates for relocations. For
instance, in the x86-64 instruction movl sym(%rip), %eax
(GNU syntax), the assembler calculates the displacement between the
program counter (PC) and sym. This distance affects the
instruction's encoding and typically triggers a
R_X86_64_PC32 relocation, unless sym is a
local symbol defined within the current section.
Both the GNU assembler and LLVM integrated assembler utilize multiple passes during assembly, with several key phases relevant to relocation generation:
Compiling C++ with the Clang API
This post describes how to compile a single C++ source file to an
object file with the Clang API. Here is the code. It behaves like a
simplified clang executable that handles -c
and -S.
Migrating comments to giscus
Followed this guide: https://www.patrickthurmond.com/blog/2023/12/11/commenting-is-available-now-thanks-to-giscus
Add the following to layout/_partial/article.ejs
1 | <% if (!index && post.comments) { %> |
Unfortunately comments from Disqus have not been migrated yet. If you've left comments in the past, thank you. Apologies they are now gone.
While you can create Github Discussions via GraphQL API, I haven't found a solution that works out of the box. https://www.davidangulo.xyz/posts/dirty-ruby-script-to-migrate-comments-from-disqus-to-giscus/ provides a Ruby solution, which is promising but no longer works.
1 | Failed to define value method for :name, because EnterpriseOrderField already responds to that method. Use `value_method:` to override the method name or `value_method: false` to disable Enum value me |
lld 20 ELF changes
LLVM 20 will be released. As usual, I maintain lld/ELF and have added some notes to https://github.com/llvm/llvm-project/blob/release/20.x/lld/docs/ReleaseNotes.rst. I've meticulously reviewed nearly all the patches that are not authored by me. I'll delve into some of the key changes.
Natural loops
A dominator tree can be used to compute natural loops.
- For every node
Hin a post-order traversal of the dominator tree (or the original CFG), find all predecessors that are dominated byH. This identifies all back edges. - Each back edge
T->Hidentifies a natural loop withHas the header.- Perform a flood fill starting from
Tin the reversed dominator tree (from exiting block to header) - All visited nodes reachable from the root belong to the natural loop
associated with the back edge. These nodes are guaranteed to be
reachable from
Hdue to the dominator property. - Visited nodes unreachable from the root should be ignored.
- Loops associated with visited nodes are considered subloops.
- Perform a flood fill starting from
Understanding and improving Clang -ftime-report
Clang provides a few options to generate timing report. Among them,
-ftime-report and -ftime-trace can be used to
analyze the performance of Clang's internal passes.
-fproc-stat-reportrecords time and memory on spawned processes (ld, and gas if-fno-integrated-as).-ftime-trace, introduced in 2019, generates Clang timing information in the Chrome Trace Event format (JSON). The format supports nested events, providing a rich view of the front end.-ftime-report: The option name is borrowed from GCC.
This post focuses on the traditional -ftime-report,
which uses a line-based textual format.
Understanding
-ftime-report output
The output consists of information about multiple timer groups. The last group spans the largest interval and encompasses timing data from other groups.
Up to Clang 19, the last group is called "Clang front-end time report". You would see something like the following.
2024年总结
一如既往,主要在工具链领域耕耘。
Blogging
I have been busy creating posts, authoring a total of 31 blog posts (including this one). 7 posts resonated on Hacker News, garnering over 50 points. (https://news.ycombinator.com/from?site=maskray.me).
I have also revised many posts initially written between 2020 and 2024.
Mastodon: https://hachyderm.io/@meowray
Skipping boring functions in debuggers
In debuggers, stepping into a function with arguments that involve function calls may step into the nested function calls, even if they are simple and uninteresting, such as those found in the C++ STL.
GDB
Consider the following example:
1 |
|
When GDB stops at the foo call, the step
(s) command will step into std::vector::back
and std::unique_ptr::operator*. While you can execute
finish (fin) and then execute s
again, it's time-consuming and distracting, especially when dealing with
complex argument expressions.