In gdb 'p /t' shows values of variables or registers in binary format. When an uint16_t or uint32_t register is read, it's hard to find the bit that I want to look at. Is there a way of formatting the output better? For example, grouping 4 digits and adding spaces, like '0000 0000 0100 0101'?
Well... I just found a way, though it's not beautiful.
'x/' shows values in variables. It has some useful formatting options.
For example, if you want to read a 32-bit register that stores the following value.
(gdb) p /t register_name
11111111111011111111100010101010
Then, you can see them byte by byte like the example below. Note that the order of the bytes are reversed.
(gdb) x/4bt ®ister_name
0x40022020: 10101010 11111000 11101111 11111111
There is no built-in way to do this. It seems like a reasonable feature to request (in gdb bugzilla).
Related
I need to reproduce the output of a hardware CRC calculator for testing purposes. It is set up for ethernet CRC 32, in trace32 format:
/CRC 32. 0x04C11DB7 1 1 0FFFFFFFF 0FFFFFFFF (checksum width, polynom, input reflection, output reflection, crc init, final XOR)
If I feed it values where the 4 bytes are equal (e.g 0x12121212 as each byte being 0x12), the output will match what I calculate using CRC32 or python.
However if I feed it any value where the 4 bytes are not equal, the results are off. For example 0x12341234 will return 0x093c454b (should be 0xa1768922).
Or 0x12345678 will return 0xAF6D87D2 (should be 0x4a090e98).
In the HW I can only select the init value and the polynomial, beyond feeding it 4 bytes to calculate. Rolling calculations(multiple words worth) behave the same way, the output is correct as long as each word fed to it has all bytes the same. Anything else, the output is off.
I am not too knowledgeable about CRC32 and has run out of ideas. Any pointers would be appreciated, what am I doing wrong here? I have double checked the polynomial, but if that was wrong, I could only get the right results extremely rarely, right?
Thank you!
You get your "should be" with the correct byte order. You get your "will return" by reversing the bytes. The bytes 12 34 56 78 gives, for the CRC you described, 0x4a090e98. The bytes 78 56 34 12 gives the CRC 0xaf6d87d2.
Your question is very vague, with no code or how it is being used. I can only guess that you are giving your CRC routine a 32-bit value instead of bytes, and it is being processed in little-endian order when you are expecting big-endian order.
I'm studying C++ using the website learncpp.com. Chapter 0.5 states that the purpose of a compiler is to translate human-readable source code to machine-readable machine code, consisting of 1's and 0's.
I've written a short hello-world program and used g++ hello-world.cpp to compile it (I'm using macOS). The result is a.out. It does print "Hello World" just fine, however, when I try to look at a.out in vim/less/Atom/..., I don't see 1's and 0', but rather a lot of this:
H�E�H��X�����H�E�H�}���H��X���H9��
Why are the contents of a.out not just 1's and 0's, as would be expected from machine code?
They are binary bits (1s and 0s) but whatever piece of software you are using to view the file's contents is trying to read them as human readable characters, not as machine code.
If you think about it, everything that you open in a text editor is comprised of binary bits stored on bare metal. Those 1s and 0s can be interpreted in many many different ways, and most text editors will attempt to read them in as characters. Take the character 'A' for example. It's ASCII code is 65 which is 01000001 in binary. When a text editor reads through the file on your computer it is processing those bits as characters rather than machine instructions, and therefore it reads in 8 bits (byte) in the pattern 01000001 it knows that it has just read an 'A'.
This process results in that jumble of symbols you see in the executable file. While some of the content happens to be in the right pattern to make human readable characters, the majority of them will likely be outside of what either the character encoding considers valid or knows how to print, resulting in the '�' that you see.
I won't go into the intricacies of how character encodings work here, but read Character Encodings for Beginners for a bit more info.
I'm working with an algorithm that uses uint16_t as the datatype. There are 4 half words in the array so I am trying to display the four half words in hex. I have not done anything other than x/4h:
(gdb) x/4h master_key
0x7fffffffd330: u"Āईᄐᤘ桷"
0x7fffffffd33c: u"桷敥\xbe0#"
0x7fffffffd346: u""
0x7fffffffd348: u"ꆋ翿"
According to the GDB | Memory:
f, the display format
The display format is one of the formats used by print (‘x’, ‘d’, ‘u’, ‘o’, ‘t’, ‘a’, ‘c’, ‘f’, ‘s’), and in addition ‘i’ (for machine
instructions). The default is ‘x’ (hexadecimal) initially. The default
changes each time you use either x or print.
I'm not sure why x is trying to print strings but I would like it to print the half words in hex.
GDB does not seem to be following the manual. I think I need to change the behavior of x and make it persistent. How do I tell GDB to print the half words in hex?
The following in in my .gdbinit but it looks like GDB is ignoring it (not a surprise).
(gdb) shell cat ~/.gdbinit
set output-radix 16
set history save on
set history size 256
set logging on
set logging overwrite on
I have an USB Device. It's a pedometer/activity tracker.
I'm able to send bytes to the device and I'm also able to retrieve bytes back.
But for some reason numbers are turned into those square characters and not into numbers... The characters that are actually letters come through just fine.
Any idea's on how to retrieve the bytes as numbers?
The expected format something like this:
The square characters are actually binary data, likely hex before 0x20 or above 0x7f.
The first 15 bytes are binary, you would need to interpret them using something approximately like the following pseudocode:
if (isascii(byte)) {
textToAppendToEditBox(byte);
} else {
textToAppendToEditBox( someKindOfSprintF( "{%02x}");
}
There are plenty of googleable examples of hex dumping code snippets that can make it look pretty
The expected format that you showed sends binary data. You first have to convert the received data to internal information, then you can pass that information to an std::ostringstream to display it in a gui.
When reading in the binary data, make sure to respect the used endianess.
I need to read in an Intel Hex file which looks something like this:
:0300000002F8D42F
:07000300020096000000005E
:07000B000200B50000000037
:030013000200D414
:03001B000200F3ED
(Yes, some lines are missing and sometimes 1 line only contains 1 byte)
The : is the start code
First 2 bytes is the byte count
Next 4 are the address in memory
Next 2 is record type
The rest is the data (except the last 2 bytes)
last 2 bytes are the checksum
More info here (wikipedia)
I need to end up with something like this (no periods, only there for readability):
:10.addr.RT.10bytesofdata.CK
If there is no data from the file for an address I am filling it with 'FF'
So what is the best way to read in and store a file like this if I am going to need to divide up and sort the information by address, byte for byte.
I was hoping to read byte by byte (?) storing the appropriate values into a 2D integer array ordered by the address.
[BC][ADDR][RT][b1][b2][b3][b4][b5][b6][b...16][ck]
[BC][ADDR][RT][b1][b2][b3][b4][b5][b6][b...16][ck]
...
I would like to stay away from using strings so I can more easily calculate checksums.
Also I am using Visual Studio.
Thanks for the help I can post more info if this was not clear enough.
Update So right now I think I'm reading in with something like this:
fscanf_s(in_file,"%2X", &BC);
fscanf_s(in_file,"%4X", &ADDR);
fscanf_s(in_file,"%2X", &RT);
The I'll print out to a file like this:
fprintf_s(out_file,"%2X", BC);
fprintf_s(out_file,"%04X", ADDR); //this pads with zeros if needed and forces 4 "digits"
fprintf_s(out_file,"%2X", RT);
Now I'm working on a routine for the data. Let me know if anyone has any good ideas. Thanks
I would suggest a Dictionary<RT, byte[]>, and just use a single flat array. Then stride through that array calculating checksums and building the output lines, if all bytes in the line were 0xFF then you can skip appending that line to your output.
Maybe Dictionary<RT, List<byte>> if you can't predict the size of each memory space in advance, but since 4 nibbles of address only allows 64k, I'd just allocate each array to that space immediately.
I'm not sure about a 2D array -- I'd just start with a big 1D array representing (in essence) the target address space. Pre-fill it with FF. Walk through the records from the hex file, and:
fill the values into your array, and
keep track of the highest and lowest addresses encountered.
When you're done, start from the lowest address encountered, and encode data 10 (10h?) bytes at a time until you reach the highest address you wrote to.