User-specified offset

[Mic92]

I would like to integrate hexyl in GDB using the python API. Therefore it would be useful if I could supply a different offset, so that input offsets in hexyl matches with the addresses in virtual memory in the process.

[Mic92]

This is what I currently came up with:

import subprocess
import tempfile

# To use, add source /path/to/script.py to your $HOME/.gdbinit file.

class Hexyl(gdb.Command):
    """
       Run hexyl on provided symbol/address. Takes the number of bytes to print as an optional parameter
    """
    def __init__(self):
        super(Hexyl, self).__init__("hexyl", gdb.COMMAND_USER)
        self.long_int = gdb.lookup_type("long")

    def invoke(self, arg, from_tty):
        argv = gdb.string_to_argv(arg)
        count = 0x100
        if argv and len(argv) > 0:
            address = argv[0]
            if len(argv) > 1:
                count = argv[1]
        else:
            address = "$sp"

        with tempfile.NamedTemporaryFile(suffix='.bin', delete=True) as f:
            gdb.execute("dump binary memory %s %s (%s + %s)" % (f.name, address, address, count))
            subprocess.call(["hexyl", f.name])

        return False

Hexyl()

Usage:

(gdb) hexyl 0x7fffffff2338
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ 38 3b 35 3b 34 38 3a 2a ┊ 2e 65 6c 3d 30 3b 33 38 │8;5;48:*┊.el=0;38│
│00000010│ 3b 35 3b 34 38 3a 2a 2e ┊ 63 6c 6a 3d 30 3b 33 38 │;5;48:*.┊clj=0;38│
│00000020│ 3b 35 3b 34 38 3a 2a 2e ┊ 67 69 74 3d 30 3b 33 38 │;5;48:*.┊git=0;38│
│00000030│ 3b 35 3b 32 34 33 3a 2a ┊ 2e 77 61 76 3d 30 3b 33 │;5;243:*┊.wav=0;3│
│00000040│ 38 3b 35 3b 32 30 38 3a ┊ 2a 2e 6d 34 76 3d 30 3b │8;5;208:┊*.m4v=0;│
│00000050│ 33 38 3b 35 3b 32 30 38 ┊ 3a 2a 2e 74 6d 6c 3d 30 │38;5;208┊:*.tml=0│
│00000060│ 3b 33 38 3b 35 3b 31 34 ┊ 39 3a 2a 2e 73 74 79 3d │;38;5;14┊9:*.sty=│
│00000070│ 30 3b 33 38 3b 35 3b 32 ┊ 34 33 3a 2a 2e 6d 70 33 │0;38;5;2┊43:*.mp3│
│00000080│ 3d 30 3b 33 38 3b 35 3b ┊ 32 30 38 3a 2a 2e 61 77 │=0;38;5;┊208:*.aw│
│00000090│ 6b 3d 30 3b 33 38 3b 35 ┊ 3b 34 38 3a 2a 2e 66 6c │k=0;38;5┊;48:*.fl│
│000000a0│ 76 3d 30 3b 33 38 3b 35 ┊ 3b 32 30 38 3a 2a 2e 64 │v=0;38;5┊;208:*.d│
│000000b0│ 65 62 3d 34 3b 33 38 3b ┊ 35 3b 32 30 33 3a 2a 2e │eb=4;38;┊5;203:*.│
│000000c0│ 63 66 67 3d 30 3b 33 38 ┊ 3b 35 3b 31 34 39 3a 2a │cfg=0;38┊;5;149:*│
│000000d0│ 2e 62 6c 67 3d 30 3b 33 ┊ 38 3b 35 3b 32 34 33 3a │.blg=0;3┊8;5;243:│
│000000e0│ 2a 2e 6d 70 67 3d 30 3b ┊ 33 38 3b 35 3b 32 30 38 │*.mpg=0;┊38;5;208│
│000000f0│ 3a 2a 2e 66 6c 73 3d 30 ┊ 3b 33 38 3b 35 3b 32 34 │:*.fls=0┊;38;5;24│
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

[sharkdp]

Thank you very much for your feedback! Integrating hexyl in gdb sounds like a very cool idea!

Can you go into a little bit more detail what kind of feature you would like to see in hexyl to make this easier?

[Mic92]

A parameter that allows to add an offset to the number reported by hexyl on the left-side would be sufficient. This way the addresses by gdb would match up with hexyl offsets. This would useful for cases where we only pass a subset of the data to hexyl, which is not limited to GDB.

[sharkdp]

Ok, so this would be similar to xxds -o <offset> option. Sounds good to me!

[matematikaadit]

So, if I understand it correctly, this is just a display option, right? i.e. hexyl still reads the binary from the start of the file, but it display them as if the file is started from a certain virtual address.

For example:

File content: [ 7f 45 4c 46 02 01 01 00 ]

$ hexyl foo
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ 7f 45 4c 46 02 01 01 00 ┊                         │•ELF•••0┊        │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘
$ hexyl --display-offset 0x408000 foo  # just for example
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00408000│ 7f 45 4c 46 02 01 01 00 ┊                         │•ELF•••0┊        │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

[sharkdp]

closed via #72 by @tommilligan