Lets try recovering a file from rm *

By mistake I deleted a source code which I spend around a day to develop. With the help of extundelete utility it is possible to recover file if same space is not reallocated by file system.

Here is what I did to recover my deleted file info_bootimg.c

sudo src/extundelete --restore-file  workspace/utils/helper_utills/bootinfo/info_bootimg.c  /dev/mapper/vg00-lv_local_mnt

"workspace/utils/helper_utills/bootinfo/" is the path relative to the root of partition

This is where the partition is mounted,

/dev/mapper/vg00-lv_local_mnt on /local/mnt type ext4 (rw)

File's absolute path is "/local/mnt/workspace/utils/helper_utills/bootinfo/info_bootimg.c"

But you have to strip "/local/mnt" to get it working.

Download extundelete from,
http://extundelete.sourceforge.net/

./configure and make

Debugging using T32 on a Multi cores/cpus

Contemporary processors are multi core/cpus. This has made life of a developer bit tougher. For eg, for the break point to hit, you need to set it on all the cpus, because you never know where the code is going to run. Another instance is to stop all the core at the same time.

Below is a set of scritps which helps you to make your job easier.

For eg we will consider working on a 4 core processor.

You need to create few cmm files. Contents and file names as shown below,

1) main.cmm
=========
GLOBAL &ScriptPath &vmlinuxPath

&ScriptPath="Z:\deleteme\T32"
&vmlinuxPath="Z:\kdevs\3.18\kdev\kobj"

globalon cmd i do &ScriptPath\initcore_all.cmm
globalon cmd pos do &ScriptPath\pos.cmm
globalon cmd load do &ScriptPath\load_all.cmm
globalon cmd ball do &ScriptPath\break_all.cmm

==========

2) initcore_all.cmm

============

intercom.execute localhost:15370 do &ScriptPath\initcore.cmm

intercom.execute localhost:15371 do &ScriptPath\initcore.cmm

intercom.execute localhost:15372 do &ScriptPath\initcore.cmm

intercom.execute localhost:15373 do &ScriptPath\initcore.cmm

============

3) initcore.cmm

==========

sys.m.a

snoop.pc ON

b.d

b.s die  /Onchip

b.s panic  /Onchip

===========

4) loadall.cmm

=========

intercom.execute localhost:15370 do &ScriptPath\load.cmm &vmlinuxPath

intercom.execute localhost:15371 do &ScriptPath\load.cmm &vmlinuxPath

intercom.execute localhost:15372 do &ScriptPath\load.cmm &vmlinuxPath

intercom.execute localhost:15373 do &ScriptPath\load.cmm &vmlinuxPath

==========

5) load.cmm

========

ENTRY &vmlinuxPath

d.load.elf &vmlinuxPath\vmlinux /NOCODE

========

6) pos.cmm
=======
intercom.execute localhost:15370 framepos 0 0 65 13
intercom.execute localhost:15371 framepos 75 0 65 13
intercom.execute localhost:15372 framepos 0 25 65 13
intercom.execute localhost:15373 framepos 75 25 65 13
========

7) break_all.cmm
===========
intercom.execute localhost:15370 break
intercom.execute localhost:15371 break
intercom.execute localhost:15372 break
intercom.execute localhost:15373 break

===========

Open four instances of T32. run main.cmm on T32 associated with core 0.

then type the i in the command line to run intercore_all.cmm

Using GDB to find structure info

As usual  load elf file

$gdb vmlinux

We are going to inspect the address layout of structure platform_device,

struct platform_device {
        const char      *name;
        int             id;
        bool            id_auto;
        struct device   dev;
        u32             num_resources;
        struct resource *resource;

        const struct platform_device_id *id_entry;
        char *driver_override; /* Driver name to force a match */

        /* MFD cell pointer */
        struct mfd_cell *mfd_cell;

        /* arch specific additions */
        struct pdev_archdata    archdata;
};


(gdb) p &((struct platform_device *)0)->name
$2 = (const char **) 0x0
(gdb) p &((struct platform_device *)0)->id
$3 = (int *) 0x8
(gdb) p &((struct platform_device *)0)->id_auto
$4 = (bool *) 0xc
(gdb) p &((struct platform_device *)0)->dev
$5 = (struct device *) 0x10

Above output shows the offset of different variables in the structure.

Enabling core dump on Ubuntu

type command,

ulimit -c unlimited

Still not present, monitor the logs here,
/var/log/apport.log

crosscompiling and gdb

As an example I m trying to see how division is implemented on arm and arm64.

created a test.c

int main(void)
{
        int a = 10;
        int b = 20;
        return (a/b);
}

Make sure to comple with -o option always because a.out doesn't has symbols

To compile for arm64
/usr2/arunks/workspace/LA.BR.1.3.1/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-gccc -o test64 test.c --sysroot=/usr2/arunks/workspace/LA.BR.1.3.1/prebuilts/ndk/9/platforms/android-17/arch-arm64/usr/

(gdb) disassemble main
Dump of assembler code for function main:
   0x00000000004005a8 <+0>:     sub     sp, sp, #0x10
   0x00000000004005ac <+4>:     mov     w0, #0xa                        // #10
   0x00000000004005b0 <+8>:     str     w0, [sp,#12]
   0x00000000004005b4 <+12>:    mov     w0, #0x14                       // #20
   0x00000000004005b8 <+16>:    str     w0, [sp,#8]
   0x00000000004005bc <+20>:    ldr     w1, [sp,#12]
   0x00000000004005c0 <+24>:    ldr     w0, [sp,#8]
   0x00000000004005c4 <+28>:    sdiv    w0, w1, w0
   0x00000000004005c8 <+32>:    add     sp, sp, #0x10
   0x00000000004005cc <+36>:    ret
End of assembler dump.

start gdb
/usr2/arunks/workspace/LA.BR.1.3.1/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gcc -o test test.c --sysroot=/usr2/arunks/workspace/LA.BR.1.3.1/prebuilts/ndk/9/platforms/android-17/arch-arm/usr/

To compile for arm
/usr2/arunks/workspace/LA.BR.1.3.1/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gdb test

start gdb
/usr2/arunks/workspace/LA.BR.1.3.1/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gdb test

Dump of assembler code for function main:
   0x00008460 <+0>:     push    {r11, lr}
   0x00008464 <+4>:     add     r11, sp, #4
   0x00008468 <+8>:     sub     sp, sp, #8
   0x0000846c <+12>:    mov     r3, #10
   0x00008470 <+16>:    str     r3, [r11, #-8]
   0x00008474 <+20>:    mov     r3, #20
   0x00008478 <+24>:    str     r3, [r11, #-12]
   0x0000847c <+28>:    ldr     r0, [r11, #-8]
   0x00008480 <+32>:    ldr     r1, [r11, #-12]
   0x00008484 <+36>:    bl      0x8498 <__divsi3>
   0x00008488 <+40>:    mov     r3, r0
   0x0000848c <+44>:    mov     r0, r3
   0x00008490 <+48>:    sub     sp, r11, #4
   0x00008494 <+52>:    pop     {r11, pc}
End of assembler dump.

So arm32 implements division in software whereas arm64 has a dedicated instruction to do this.

Banked registres ARM v7

Interpreting values in stack using crash utility

This post shows how to figure out the values in stack using crash utility.

Let me explain a scenario:
Speculation: Process named Binder_5 is in the runqueue holding cgroup_mutex and looping there infinitely.

Below is the do while code which I m suspecting,
File: kerne/cgroups.c
Function: cgroup_attach_task
kernel version:3.10.17

                                                                    Figure 1:

Backtrace of Binder_5 task is as follows,

                                                                      Figure 2:

So from the do while, task_cgroup_from_root is called and this process(binder_5) was preempted out. It was because of some other high priority task might have come.

To confirm that we are in this loop for ever, we need to check the if condition(marked in red box in figure 1). Lets take the objdump of vmlinux and see how to figure out the value of ent.cgrp and cgrp. Both will be stored in stack.

Figure 3 show the partial objdump of function cgroup_attach_task(corresponding c function is shown in figure 1). It is taken using the following command.
$ arm-none-linux-gnueabi-objdump -D vmlinux > vmlinux_objdump.txt

                                                                      Figure 3:

Now we need to find the value of r5 and r0. And if they are same, then my speculation of infinite loop is correct. Tough job ahead :-). Lets have fun.

Finding the value of r5:
If we are lucky the value of r5 will be pushed in to stack during entry of function task_cgroup_from_root.
Here is the objdump:

                                                                     Figure 4:

Yes it is pushed to the stack.
Now figure 5 explains below how to find out the value of r5.
The left part of the figure 5 is created by printing the frame of task binder_5 using crash tool.
The command used,
crash> bt -f 2077
whree 2077 is the pid of process binder_5

                                                                                     Figure :5

push    {r4, r5, fp, ip, lr, pc}

In above instruction, pc will be stored at highest address in stack, followed by lr. And so on.
This is because arm linux stack type is full descending.

So value of r5 = 0xed306c00.

Finding the value of r0:
Now from figure 3, r0 is also stored at fp - 84 th location(marked in red box). so if we look at that location we could get what was the value of r0 when task_cgroup_from_root returned last time.

So for this, we need to find the value of fp first. This will be stored in the frame of task_cgroup_from_root. Same way as our r5 was stored.

Below figure shows how we found the value of fp.
The left side of figure 6 show the backtrace with frames same as figure 5. This time I used the notepad++.

                                                                                     Figure :6

So value of r0 and r5 are same and the speculation of of infinite loop is proved.
This was a bug in the kernel 3.10 and is fixed later. commit

Thanks,
Arun