I'm working on the bomb lab from CMU CSAPP class from this site, the bomb binary is here.
I found a very interesting thing using gdb while i am defusing phase_3 of the bomb. I need to use a lot p/x [MEMORY_ADDRESS] while defusing phase_3, however, the output of the print command looks strange to me.
I tried to print against different memeory address using p/x *[MEMORY_ADDRESS], the length of the output varied a lot. It sometimes gave me a 8-char output like 0x18244c8b, sometimes gave me a 6-char output like 0x28250c, or sometimes only a 0x0.
In my understanding, while using p/x *[MEMORY_ADDRESS], we are only print the hex value of the single byte resides in that memory address, which should only give us a 2-char output in hex format. How does gdb decide how many bytes it will print while executing p/x?
Thanks for looking at this problem.
My understanding is that, gdb is treating my memory address as a pointer to int, thus will always try to print 4 bytes, the reason i'm seeing varying output is because some ouputs have so many leading zeros. So 0xfe is actually 0x000000fe.
In this scenario, gdb's print command is always printing 4 bytes.
I'm using GDB to debug code that was assembled with
nasm -felf64 -Fdwarf
when I want to examine the value at a label symbol, say
var_h: dq -1
using
print var_h
GDB assumes that the value is 32-bit and only gives me the lowest 4 bytes
x \1gx $var_h
gives an error along the lines of "cannot convert value to integer'
Very grateful for any ideas!
This should work:
(gdb) x/gx &var_h
Your other commands, as well as "along the lines of ..." make no sense.
Details matter, and you should always show actual commands you used and output you received, not vague approximations thereof.
I am trying to troubleshoot a bus error with some inline SSE2 assembly. The source code has a macro that uses 5 pointers, and I suspect one of them is not aligned.
I set a breakpoint on the source line. But when I perform a disass, it disassembles from the top of the function, and not where the debugger is stopped. There are hundreds of lines of assembly, so its not really helpful to me. Pressing ENTER 30 to 40 times in response to "Press ENTER to continue" got old very quickly.
I tried a disass $pc, but it dsassembled from the top of the function. I also tried a disass . (with the dot meaning "here"), but that resulted in:
A syntax error in expression, near `.'.
What does GDB use to denote "here"?
You were correct with the use of $pc to represent the current location. The reason that this did not do what you expected when used with the disassemble command is that the disassemble command tries by default to disassemble the function containing the given address which is what you are seeing.
There are alternative forms that can be given to disassemble, for example start,end where start and end are addresses, or start,+length where start is an address and length is a number of bytes.
Try help disassemble at the gdb prompt for more information.
As an alternative you can also use the x (examine) command to display instructions, without the smart find the beginning of the function behaviour, so x/10i $pc will display 10 instructions starting from $pc. This can be helpful if you only want the instructions disassembled, however you don't have access to the /m or /r modifiers that are available on the disassemble command. These modifiers display interleaved source and assembler (for /m) or the raw instruction bytes (for /r).
Also, if the whole press ENTER to continue thing is getting old then you can try set height 0 to turn off the pager, do make sure that you have enough scroll back in your terminal though :)
I'm using Code::Blocks on Ubuntu 10.10 (Maverick Meerkat). I have connected a Mac keyboard and set the keyboard settings to "Swiss German Mac". Now whenever I write an equals sign, followed by a space (something like width = 100) I get the error message: stray '\302' in program.
I know this error means that there is a non-standard character in the text file.
When I delete the space character, the program compiles just fine. So that means Code::Blocks adds some sort of special character. But I can't see why this happens. What is the reason?
What character does '\302' stand for?
[UPDATE]
I got a little further investigating the problem. I get this stray when I use the combo Shift + Space. Now that I know it doesn't happen that often any more. But it's still rather annoying especially when writing code... Is there a way to turn off this combo in X11?
[SOLVED]
Thanks to Useless's answer, I was able to solve the "issue". It's more of a feature actually. Shift + space created a spacenolinebreak by default. So by changing the xmodmap with
xmodmap -e "keycode 65 = space space space space space space"
this behavior was overridden and everything works fine now.
Since you're sure it's caused by hitting Shift + Space, you can check what X itself is doing by. First, run xev from the command line, hit Shift + Space and check the output. For example, I see:
$ xev
KeyPress event, serial 29, synthetic NO, window 0x2000001,
root 0x3a, subw 0x0, time 4114211795, (-576,-249), root:(414,593),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0x2000001,
root 0x3a, subw 0x0, time 4114213059, (-576,-249), root:(414,593),
state 0x1, keycode 65 (keysym 0x20, space), same_screen YES,
XLookupString gives 1 bytes: (20) " "
XmbLookupString gives 1 bytes: (20) " "
XFilterEvent returns: False
...
Then, run xmodmap -pk and look up the keycode (space should be 65 as above, but check your xev output).
If you see something like
65 0x0020 (space)
Then X isn't doing this. On the other hand, if I pick a character key which is modified by shift, I see something like this:
58 0x006d (m) 0x004d (M)
If you have two or more keysyms for your keycode, X is the culprit. In that case, something like xmodmap -e 'keycode 65 space' should work.
\302 stands for the octal representation of byte value the compiler encountered. It translates to 11000010 in binary, which makes me think it's the start of a two byte UTF-8 sequence. Then this sequence must be:
11000010 10??????
Which encodes the binary Unicode point 10??????, which can be anything from U+80 to U+BF.
Several characters starting from U+80 are special spaces and breaks which usually are not shown inside a text editor.
Probably it's not your editor, but Xorg, that emits these characters due to your keyboard settings. Try switching to a generic US keyboard and test if the problems persists.
'\302' is C notation for the octal number 3028, which equals C216 and 19410. So it's not ASCII.
Which character it maps to depends on the encoding. In Latin-1, it's the  character, for instance.
I have seen this type of issue when copying and pasting from web pages or other electronic documents. The common culprits would be invalid quotes like ` instead of ', or something alike. Try to use the compiler error to guide you into where in the file the error might be.
That sounds like some kind of encoding issue. I haven't used Code::Blocks for years, so I am not sure if it allows you to pick different encodings.
How about opening your code file with gedit and saving it as UTF-8, and then try again? But it sounds rather strange that you get such an issue using space characters.
I've seen this problem in my Linux box with a Finnish keyboard.
It also happens with Emacs, etc. I don't have a good solution for it, but I guess reports about the fact that it happens elsewhere are also useful...
If you open your file in Emacs and set-buffer-file-coding-system to something like "unix" or some ASCII variety, then when you try to save, it'll warn you that the buffer contains unrepresentable characters and points you to them so you can fix them.
I had the same issue by modified a US ASCII example file.
So I convert it in UTF-8, here are GNU/Linux command:
iconv -c -t us-ascii -f utf-8 source_file -o dest_file
And then add my modifications… no more errors!
To verify initial encoding, use
file -i source_file
I should add a non-ASCII character to allow iconv do the job!!??
I decided to move the file from a MAC book to a Linux box and used email with my icloud.com address. When I opened the transferred file the errors had gone and the file now compiles !
In my multithreaded program, I am logging process id and thread id. Thread id is generated using pthread_self() function. when I print in hex, generally it has 12 characters out of which first four are always common and I don't want to log them.
What is the best way in C++ to print last 8 characters, I tried to use boost::format but couldn't figure out how to print last 8 characters.
e.g
Here printing process id in decimal and thread id in hex.
std::cout << boost::format("%5d|%8X") %getpid() %pthread_self()
I have made it work with below solution but I don't like the magic number 10000000000
std::cout << boost::format("%5d|%8X") %getpid() %(pthread_self()%10000000000)
NOTE: For simplicity, here I used std::cout. In my application, I use boost::log so if there is a way to do using boost log, that's preferred.
Here is an example: 7f08 is common and doesn't add any value in debugging.
14833|7f084b7fe700
14833|7f084bfff700
14833|7f0850dec700
14833|7f08515ed700
14833|7f0851dee700
14833|7f08525ef700
14833|7f0852df0700
14833|7f08535f1700
Your magic constant should be in hex:
pthread_self() & 0xffffffff
This lets bits in the bottom 8 hex digits pass through unchanged, but sets bits in the higher hex digits to 0. They should then be suppressed, since you haven't specified leading 0 printing.
1) declare a char[13] variable on stack
2) sprintf there your thread id in %x form
3) then if you take a pointer to 4-th element of the array it will be your 8-char string - you can log it via whatever you like
Put the computation in a new function properly named, like last_part_of_thread_id(). Then the code will not look that magic inside such a function.