Linux Kernel Module Cheat

24.22.4.2.5. TimingSimpleCPU analysis #5

Executes TimingSimpleCPU::fetch().

The log shows that event ID 43 is now executing: we had previously seen event 43 get scheduled and had analyzed it to be the initial fetch.

We can step into TimingSimpleCPU::fetch() to confirm that the expected ELF entry point is being fetched. We can inspect the ELF with:

./run-toolchain --arch aarch64 readelf -- \
  -h "$(./getvar --arch aarch64 userland_build_dir)/arch/aarch64/freestanding/linux/hello.out"

which contains:

  Entry point address:               0x400078

and by the time we go past:

TimingSimpleCPU::fetch()
{
    ...
    if (needToFetch) {
        ...
        setupFetchRequest(ifetch_req);
        DPRINTF(SimpleCPU, "Translating address %#x\n", ifetch_req->getVaddr());
        thread->itb->translateTiming(ifetch_req, thread->getTC(),
                &fetchTranslation, BaseTLB::Execute);

BaseSimpleCPU::setupFetchRequest sets up the fetch of the expected entry point by reading the PC:

p/x ifetch_req->getVaddr()

Still during the execution of the fetch, execution then moves into the address translation ArmISA::TLB::translateTiming, and after a call to:

TLB::translateSe

the packet now contains the physical address:

_paddr = 0x78

so we deduce that the virtual address 0x400078 maps to the physical address 0x78. But of course, let me log that for you by adding --trace MMU:

      0: MMU: system.cpu.workload: Translating: 0x400078->0x78

If we try --trace DRAM we can see:

      0: DRAM: system.mem_ctrls: recvTimingReq: request ReadReq addr 120 size 4

where 120 == 0x78 (it logs addresses in decimal? Really??) and the size 4 which is the instruction width.

Now that we are here, we might as well learn how to log the data that was fetched from DRAM.

Fist we determine the expected bytes from the disassembly:

./disas --arch aarch64 --userland userland/arch/aarch64/freestanding/linux/hello.S _start

which shows us the initial instruction encodings near the entry point _start:

   0x0000000000400078 <+0>:     20 00 80 d2     mov     x0, #0x1                        // #1
   0x000000000040007c <+4>:     e1 00 00 10     adr     x1, 0x400098 <msg>

Now, TODO :-) The DRAM logs don’t contain data. Maybe this can be done with CommMonitor, but it is no exposed on fs.py