Resolve length limit with xb command in gdb - gdb

I need to copy the hex bytes in xb command, but gdb print them in multiple lines, and I had to remove the memory address from the output
(gdb) x/20xb 0x00007ffff7e84000
0x7ffff7e84000 <opendir>: 0xf3 0x0f 0x1e 0xfa 0x41 0x55 0x41 0x54
0x7ffff7e84008 <opendir+8>: 0x55 0x53 0x48 0x81 0xec 0xa8 0x00 0x00
0x7ffff7e84010 <opendir+16>: 0x00 0x64 0x48 0x8b
Tried set width unlimited but it didn't work.
What should I do?
EDIT
Full session while testing Employed Russian's solution:
# gdb /bin/ls
Reading symbols from /bin/ls...
(No debugging symbols found in /bin/ls)
(gdb) b opendir
Breakpoint 1 at 0x4870
(gdb) r
Starting program: /usr/bin/ls
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, 0x00007ffff7e84000 in opendir () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) define xb
Type commands for definition of "xb".
End with a line saying just "end".
> set var $j = 0
> while $j < $arg1
> printf "0x%02x ", (char *) $arg0[$j++]
> end
> printf "\n"
>end
(gdb) xb 0x00007ffff7e84000 20
cannot subscript something of type `long'
(gdb)

Test program:
int main()
{
char buf[] = "abcdefghijklmopqrstuvwxyz";
return 0;
}
gcc -g t.c
cat > xb.txt <<'EOF'
define xb
set var $j = 0
while $j < $arg1
printf "0x%02x ", ((char *) $arg0)[$j++] & 0xFF
end
printf "\n"
end
EOF
gdb -q -x xb.txt ./a.out
Reading symbols from ./a.out...
(gdb) start
Temporary breakpoint 1 at 0x1129: file t.c, line 3.
Starting program: /tmp/a.out
Temporary breakpoint 1, main () at t.c:3
3 char buf[] = "abcdefghijklmnopqrstuvwxyz";
(gdb) n
4 return 0;
(gdb) x/16bx buf
0x7fffffffdad0: 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68
0x7fffffffdad8: 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f 0x70
(gdb) xb buf 16
0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f 0x70
(gdb) xb buf 27
0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7a 0x00

Related

gdb print hex array in single byte mode

I'm using x/20x to print binary data in gdb
(gdb) x/20x 0x555555558df0
0x555555558df0: 0xfa1e0ff3 0x56415741 0x54415541 0x55fc8941
I wanted to print it in single byte like this:
0xf3 0x0f 0x1e 0xfa 0x41 0x57 0x41 0x56 ...
Is that possible?
EDIT
I've tried xb command as j6 suggested, but how can I print all of them in a single line?
(gdb) x/20xb 0x00007ffff7e84000
0x7ffff7e84000 <opendir>: 0xf3 0x0f 0x1e 0xfa 0x41 0x55 0x41 0x54
0x7ffff7e84008 <opendir+8>: 0x55 0x53 0x48 0x81 0xec 0xa8 0x00 0x00
0x7ffff7e84010 <opendir+16>: 0x00 0x64 0x48 0x8b
Try format xb, which is format x (hex), size b (bytes):
(gdb) x /8xb argv
0x7fffffffdc88: 0x20 0xe1 0xff 0xff 0xff 0x7f 0x00 0x00
help x is your friend.

Why Glib::VariantBase::store method ruins the start of given buffer

The fun of working with Glib::VariantBase might be priceless. But brings up many obstacles with itself as well. I am having hard time to understand why the very basic Glib::VariantBase::store method is changing the start of my buffer.
Please assume i have a buffer allocated enough, better to write it down :
my_beautiful_buffer = static_cast<char*>(std::malloc(1024));
Then i would like to add a uint64_t variable to its beginning :
uint64_t my_humble_var = 1;
*reinterpret_cast<uint64_t*>(my_beautiful_buffer) = my_humble_var;
Lets read the buffer with printf
for (int i = 0; i < 8; i++) printf("0x%x ", *(unsigned char*)(my_beautiful_buffer+i));
+++++++++my_beautiful_buffer+++
0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Lets create a rather complex GlibVariable
using myStrangeVarType = Glib::Variant<std::map<Glib::ustring,std::map<Glib::ustring, std::tuple<Glib::VariantBase, std::uint64_t>>>>
myStrangeVarType data = createData(); // createData method statically defines variable and and copies
Now lets store this newly created variable
data.store((my_beautiful_buffer + sizeof(std::uint64_t)));
Can we read all the data in our beautiful buffer
for (int i = 0; i < data.get_size() + sizeof(std::uint64_t); i++) printf("0x%x ", *(unsigned char*)(m_buffer+i));
+++++++++Data Written+++++++
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x61 0x70 0x70 0x49 0x64 0x31 0x2f 0x64 0x61 0x74 0x61 0x62
0x61 0x73 0x65 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x6b 0x65 0x79 0x31 0x0 0x0 0x0 0x0 0x73
0x74 0x72 0x69 0x6e 0x67 0x20 0x76 0x61 0x6c 0x75 0x65 0x0 0x0 0x73 0x0 0x62 0x67 0xbc 0x0 0x0
0x0 0x0 0x0 0xf 0x5 0x0 0x0 0x0 0x0 0x0 0x0 0x6b 0x65 0x79 0x32 0x0 0x0 0x0 0x0 0xd2 0x4 0x0
0x6e 0x0 0x0 0x0 0x0 0x62 0x67 0xbc 0x0 0x0 0x0 0x0 0x0 0x4 0x5 0x22 0x42 0x11 0x0
Okay At this point what happened to my first 8 bytes, why the very first byte 0x1 is vanished ?
The problem has solved with some changes in the createData method.
The method was producing a Glib::VariantBase with a{sa{s(vt)}} type, apparently packing and unpacking custom types is not really strong point of Glib::Variant.
I had to convert my object into just v type. And the problem has fixed.
This is how i have changed the type:
GVariant* gVariant = g_variant_new("v", value.gobj());
Glib::VariantBase variantValue = Glib::VariantBase(gVariant);
return variantValue;
And earlier i was just returning the value without doing any of these conversions.
Another way to fix the problem was just calling value.get_size(); and return it afterwards.
value.get_size();
return value;
Apparently that call internally causes the variant to be serialized.

What does ZTV,ZTS,ZTI mean in the result of gdb x/nfu "vtable_address"?

1. the code
class Parent {
public:
virtual void Foo() {}
virtual void FooNotOverridden() {}
};
class Derived : public Parent {
public:
void Foo() override {}
};
int main() {
Parent p1, p2;
Derived d1, d2;
}
2. gdb command
(gdb) x/300xb 0x400b30
0x400b30 is the first address of d's vtable.
3. gdb result
0x400b30 <_ZTV7Derived>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x400b38 <_ZTV7Derived+8>: 0x80 0x0b 0x40 0x00 0x00 0x00 0x00 0x00
0x400b40 <_ZTV7Derived+16>: 0x60 0x0a 0x40 0x00 0x00 0x00 0x00 0x00
0x400b48 <_ZTV7Derived+24>: 0x70 0x0a 0x40 0x00 0x00 0x00 0x00 0x00
0x400b50 <_ZTS7Derived>: 0x37 0x44 0x65 0x72 0x69 0x76 0x65 0x64
0x400b58 <_ZTS7Derived+8>: 0x00 0x36 0x50 0x61 0x72 0x65 0x6e 0x74
0x400b60 <_ZTS6Parent+7>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x400b68 <_ZTI6Parent>: 0x70 0x20 0x60 0x00 0x00 0x00 0x00 0x00
4. question
What does _ZTV, _ZTS, _ZTI mean in <_ZTV7Derived>, <_ZTS7Derived>, <_ZTI6Parent>?
It is the way the C++ symbol names are mangled by your development platform. You can use the c++filt command line tool from GNU Binutils to find out:
$ c++filt _ZTV7Derived
vtable for Derived
$ c++filt _ZTS7Derived
typeinfo name for Derived
$ c++filt _ZTI6Parent
typeinfo for Parent
More specifically, it is the mangling defined by the Itanium or IA-64 C++ ABI which is also used on x86_64 (because the System V Application Binary Interface - AMD64 Architecture Processor Supplement says so in section 9.1 titled "C++"). See section on "Virtual Tables and RTTI" in the Itanium C++ ABI for the exact mangling details.

c++ boost filtering_streambuf read only some data

I try to create filter which would first read body size from stream and then consume only body_size bytes from stream. Although output stream is correctly created, yet for some reason all data from input stream is read. Is there a way to correct this behaviour?
struct body_size_filter {
size_t body_size;
size_t bytes_read;
typedef char char_type;
typedef boost::iostreams::multichar_input_filter_tag category;
template<typename Source>
std::streamsize read(Source& src, char* s, std::streamsize n)
{
if (bytes_read >= body_size + 4)
{
return -1;
}
int c;
// read body size
while (bytes_read < 4 && (c = boost::iostreams::get(src)) != EOF && c != boost::iostreams::WOULD_BLOCK)
{
body_size = body_size | (static_cast<size_t>(c) << (24 - 8 * bytes_read));
bytes_read++;
}
if (bytes_read < 4)
{
return c;
}
char* first = s;
char* last = s + n;
while (bytes_read < body_size + 4 && first != last && (c = boost::iostreams::get(src)) != EOF && c != boost::iostreams::WOULD_BLOCK )
{
*first++ = c;
bytes_read++;
}
std::streamsize result = static_cast<std::streamsize>(first - s);
return result == 0 && c != boost::iostreams::WOULD_BLOCK ? -1 : result;
}
body_size_filter()
{
body_size = 0;
bytes_read = 0;
}
};
and usage
boost::iostreams::filtering_streambuf<boost::iostreams::input> in;
in.push(body_size_filter());
in.push(buf);
boost::asio::streambuf body_buf;
boost::iostreams::copy(in, body_buf); // after this call buf.size() == 0 - i was expecting some data to be left in buffer
I suppose it's because of the way copy is implemented. It looks like it just exhausts the source reading blocks of some size (e.g. 128 bytes by default, but the blocksize can be overridden using the third argument to copy).
So, by the time your filter knows it's time to stop reading, the source has already been polled for too much.
I'd fix it by making a proper function to do the copy instead (after all, you do not want to copy streams. You want to read a BSON-like document off the source):
template <typename Source, typename Dest>
std::streamsize bson_copy(Source& src, Dest& dst) {
unsigned char bytes[4];
auto n = src.sgetn(reinterpret_cast<char*>(+bytes), 4);
assert(n == 4);
n = 0;
n = (n << 8) + bytes[0];
n = (n << 8) + bytes[1];
n = (n << 8) + bytes[2];
n = (n << 8) + bytes[3];
std::cout << "\n\nLength: " << n << "\n";
std::istreambuf_iterator<char> it(&src);
std::copy_n(it, n, std::ostreambuf_iterator<char>(&dst));
++it; // somehow copy_n leaves the input iterator unincremented, so a `sbumpc` would be in order (?!)
return n;
}
DEMO and test
Here's a complete and working example.
Live On Coliru
int main() {
boost::asio::streambuf buf, body_buf;
write_bson(buf);
append_deadbeef(buf);
append_deadbeef(buf);
append_deadbeef(buf);
auto n = bson_copy(buf, body_buf);
std::cout << "bson_copy: " << n << "\n";
dumpoutput(body_buf);
std::cout << "remain: " << std::dec << buf.in_avail() << "\n";
verify_deadbeef(buf);
verify_deadbeef(buf);
verify_deadbeef(buf);
std::cout << "remain: " << std::dec << buf.in_avail() << "\n";
}
Prints the (correct) output:
Length: 257
bson_copy: 257
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f
0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f
0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f
0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f
0x60 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f
0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7a 0x7b 0x7c 0x7d 0x7e 0x7f
0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 0x8a 0x8b 0x8c 0x8d 0x8e 0x8f
0x90 0x91 0x92 0x93 0x94 0x95 0x96 0x97 0x98 0x99 0x9a 0x9b 0x9c 0x9d 0x9e 0x9f
0xa0 0xa1 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7 0xa8 0xa9 0xaa 0xab 0xac 0xad 0xae 0xaf
0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf
0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf
0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0xd9 0xda 0xdb 0xdc 0xdd 0xde 0xdf
0xe0 0xe1 0xe2 0xe3 0xe4 0xe5 0xe6 0xe7 0xe8 0xe9 0xea 0xeb 0xec 0xed 0xee 0xef
0xf0 0xf1 0xf2 0xf3 0xf4 0xf5 0xf6 0xf7 0xf8 0xf9 0xfa 0xfb 0xfc 0xfd 0xfe 0xff
0x00 remain: 12
verify: 0xdeadbeef
verify: 0xdeadbeef
verify: 0xdeadbeef
remain: 0

Formatting on gdb examine memory

When debugging a C/C++ code, I examine memory using the following command
(gdb)x/32xub data
0x7fef824b2c6a: 8 0 39 235 101 169 0 30
0x7fef824b2c72: 73 219 25 195 8 0 69 0
0x7fef824b2c7a: 0 60 17 223 64 0 54 6
0x7fef824b2c82: 245 43 85 190 0 3 147 32
I would like have 16 bytes in a row and each byte shows in 2 hex digits.
Not sure what to do. Don't see any help from reference manual.
Any ideas? Thanks.
UPDATE1
Just realized that when doing it again, it shows every bytes in hexdigits. However, it's 8 bytes per row, not 16.
(gdb) x/32x prevPkt
0x7fef824b2c6a: 0x08 0x00 0x27 0xeb 0x65 0xa9 0x00 0x1e
0x7fef824b2c72: 0x49 0xdb 0x19 0xc3 0x08 0x00 0x45 0x00
0x7fef824b2c7a: 0x00 0x3c 0x11 0xdf 0x40 0x00 0x36 0x06
0x7fef824b2c82: 0xf5 0x2b 0x55 0xbe 0x00 0x03 0x93 0x20
You can do this with a macro. (This is adapted from my answer to a similar question).
define xb16
dont-repeat
set $addr = (char *)($arg0)
set $endaddr = $addr + $arg1
while $addr < $endaddr
printf "%p: ", $addr
set $lineendaddr = $addr + 16
if $lineendaddr > $endaddr
set $lineendaddr = $endaddr
end
set $a = $addr
while $a < $lineendaddr
printf "0x%02x ", *(unsigned char *)$a
set $a++
end
printf "\n"
set $addr = $addr + 16
end
end
document xb16
usage: xb16 address count
outputs bytes in hex, 16 per row
end