Correctly parse offset from info proc mappings output (#1096)

[mjklbhvg]

Description

Fix the Offset column in the vmmap command by getting the offset from the correct column in parse_gdb_info_proc_maps.

Before:

gef➤  vmmap
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000555555554000 0x0000555555558000 0x0000000000004000 r-- /usr/bin/ls
0x0000555555558000 0x000055555556e000 0x0000000000016000 r-x /usr/bin/ls
0x000055555556e000 0x0000555555577000 0x0000000000009000 r-- /usr/bin/ls
0x0000555555577000 0x0000555555579000 0x0000000000002000 r-- /usr/bin/ls
0x0000555555579000 0x000055555557a000 0x0000000000001000 rw- /usr/bin/ls
0x000055555557a000 0x000055555557b000 0x0000000000001000 rw- [heap]

After:

gef➤  vmmap
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000555555554000 0x0000555555558000 0x0000000000000000 r-- /usr/bin/ls
0x0000555555558000 0x000055555556e000 0x0000000000004000 r-x /usr/bin/ls
0x000055555556e000 0x0000555555577000 0x000000000001a000 r-- /usr/bin/ls
0x0000555555577000 0x0000555555579000 0x0000000000023000 r-- /usr/bin/ls
0x0000555555579000 0x000055555557a000 0x0000000000025000 rw- /usr/bin/ls
0x000055555557a000 0x000055555557b000 0x0000000000000000 rw- [heap]

info proc mappings:

gef➤  info proc mappings
process 18800
Mapped address spaces:

          Start Addr           End Addr       Size     Offset  Perms  objfile
      0x555555554000     0x555555558000     0x4000        0x0  r--p   /usr/bin/ls
      0x555555558000     0x55555556e000    0x16000     0x4000  r-xp   /usr/bin/ls
      0x55555556e000     0x555555577000     0x9000    0x1a000  r--p   /usr/bin/ls
      0x555555577000     0x555555579000     0x2000    0x23000  r--p   /usr/bin/ls
      0x555555579000     0x55555557a000     0x1000    0x25000  rw-p   /usr/bin/ls
      0x55555557a000     0x55555557b000     0x1000        0x0  rw-p   [heap]

Checklist

• My code follows the code style of this project.
• My change includes a change to the documentation, if required.
• If my change adds new code, adequate tests have been added.
• I have read and agree to the CONTRIBUTING document.

[github-actions]

🤖 Coverage update for b72049c 🟢

	Old	New
Commit	29fb74e	b72049c
Score	71.5548%	71.5548% (0)

[Grazfather]

good eye. Seems we didn't test the offset. Could you please add that (in tests/gef_memory.py).

[mjklbhvg]

I'm not really sure if this is the right way to test this.
It seems like the test binaries are just built using the system
c compiler, so relying on its output by hardcoding section offsets
feels a bit wrong. Any other ideas?

[github-actions]

🤖 Coverage update for 46dbc3b 🟢

	Old	New
Commit	29fb74e	46dbc3b
Score	71.5548%	71.5548% (0)

[Grazfather]

We could maybe use readelf or something to get the offsets?

[github-actions]

🤖 Coverage update for c7a19f8 🟢

	Old	New
Commit	29fb74e	c7a19f8
Score	71.5548%	71.5548% (0)

[mjklbhvg]

I had a little bit of trouble trying to get the readelf idea to work,
because readelf reports slightly different offsets than gdb:

readelf --segments /tmp/default.out

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
...
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000690 0x0000000000000690  R      0x1000
  LOAD           0x0000000000001000 0x0000000000001000 0x0000000000001000
                 0x00000000000001a1 0x00000000000001a1  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x00000000000000ec 0x00000000000000ec  R      0x1000
  LOAD           0x0000000000002dd0 0x0000000000003dd0 0x0000000000003dd0
...

The offsets for the load segments are 0, 0x1000, 0x2000 and 0x2dd0,
but when loaded, the last offset will become 0x2000 (probably to
ensure page alignment?). But I am not confident I can correctly account for
this in a test.

Instead, I now open /proc/PID/maps and check that the offsets from
info proc mappings match - which is much simpler and more
robust than hardcoding the expected values.

[Grazfather]

Nice!