GDB: How does one format breakpoint output? - debugging

Currently, I'm running GDB with the set disassemble-next-line on setting. For each line, this gives me a format that looks like:
0x08120921 <arith_driver+1>: 57 push %edi
Instead, I'd like the line to look like:
0x8120921<arith_driver+1>data.c:2577 push %edi M[0xffffc9c4]=0x084073c2 esp=0xffffc9c4
where M[address] represents a location in memory and esp refers to the register. Everything else is fairly self-explanatory. It seems like there should be a way to specify assembly code output format, but I can't find anything. Any help?

There's no built-in way to do this. You can maybe do some of it by modifying the gdb source code.

Related

What does this backslash do in this assembly code?

I am not sure what the difference is in these push lines. (trimmed down from Linux's x86/entry/calling.h, with the xor-zero clearing removed.)
.macro PUSH_AND_CLEAR_REGS rdx=%rdx rax=%rax save_ret=0
pushq \rdx
pushq \rax
pushq %r11
pushq %r12
.endm
Do both push onto the stack? Or do the first two push lines do something different? I am on linux using the GNU toolchain.
These lines where found in a .h file that's included by .S asm source files.
Also can anyone tell me what this code does?
.macro PUSH_AND_CLEAR_REGS rdx=%rdx rax=%rax save_ret=0
Specifically the code after PUSH_AND_CLEAR_REGS.
Inside a GAS .macro, you use \foo to refer to a macro parameter called foo.
The .macro you're looking at has 3 args with default values; presumably in some use-case they want to get alternate values saved in place of what's actually in RAX and RDX. But the rest of the registers get saved and xor-zeroed as normal.
So after macro expansion, yes it's just push %rdx and push %rax, same as the push %r11 and push %r12.
IDK if you were looking at an old version of Linux, but this is in a .h that's included by other .S hand-written asm source files, not by .c sources. I fixed your question for you.
I thought the comment on the GAS macro definition was was pretty clear about the purpose of this macro. See the github link I added to your question.

Is it possible to make writeable variables in .text segment using DB directive in NASM?

I've tried declaring variables in .text segment using e.g. file_handle: dd 0.
However, trying to store something in this variable like mov [file_handle], eax results in a write error.
I know, I could declare writeable variables in the .data segment, but to make the code more compact I'd like to try it as above.
Is the only possibility to use the stack for storing these value (e.g. the file handle), or could I somehow write to my variable above?
Executable code segments are not writable by default. This is a basic security precaution. No, it's not a good idea. But if you insist, as this is a toy project anyway, go ahead.
You can make yours writable by letting the linker know to mark it so, e.g. give the following argument to the MS linker:
link /SECTION:.text,EWR ....
You can actually arrange for the text segment of your Windows process to be mapped read+write+execute, see #Kuba's answer. This might also be possible on Linux with ELF binaries; I think ELF has similar flags for segments.
I think you could also call a Windows function (VirtualProtect) to change the mapping of your text segment to read+write+execute from inside your process.
Overall this sounds like a terrible idea, and you should definitely keep temporaries on the stack like a C compiler would, if you want to avoid having a data page.
Static storage for things you only use in part of the program is wasteful.
No it's not possible to have writable "variable" in .text section of an assembly program.
When writing file_handle: dd 0 in the .text section and then assemblying, your label file_handle refers to an address located in the text section of your binary. However the text section is read-only.
If the text section wasn't only read-only accessible, a program could modify itself while executing.

Assembly ".set" directive emitting symbol

In some kernel-mode assembly source I have a line that looks like this:
; excerpt #1
.set __framesize, ROUND_TO_STACK(localvarsize)
(localvarsize is a parameter to a C-preprocessor macro, if you’re wondering.) I assume that __framesize is a compile-time variable that is usable in .if statements, and is then discarded. However, I find references to a symbol named __framesize in the symbol table and disassembly of my kernel. The symbol is defined (as output by nm -m) as such:
; excerpt #2
0000000000000000 (absolute) non-external __framesize
The usage of __framesize in compiler-generated assembly is as such:
; excerpt #3
movq %gs:__framesize, %rax
movq 0x140(%rax), %r15
Given what I understand of my compiler and my kernel, excerpt #3 should be emitted as movq %gs:0x140, %r15, and that code should work. (The code that is actually being emitted from the C as excerpt #3 is causing a triple fault on the second line.)
I have two questions:
Should this __framesize symbol be emitted into my binary by the assembler when used in this fashion? If possible, how can I suppress it?
Would this usage of __framesize cause a problem like what is discussed above?
I am using GAS assembler syntax and the Xcode 7.1.1 assembler, and a Mach-O output format, if it is useful.
The GNU as manual says that .set modifies the value(i.e. address) and/or type of an existing symbol. It's synonymous with .equ, so it can be used to set/modify assembler macro variable, or to mess around with symbols which are also labels.
If __framesize is showing up in the object file, then it's probably declared somewhere else.
Try looking at the disassembly output, to see what really happened.

LC3 Starting Address of the File

For my LC3 assignment, I need to enter x3100 for the starting address of the file, how would I do that? Like what opcode would I need, I am not really sure among the ones we've studied so far.
You would use
.ORIG x3100
At the beginning of your code. It's called a pseudo-op or assembler directive, because only the assembler uses it.

windbg:Getting source code file at give address like "u address"

I have my windbg all set with srcpath and all.
I have added a breakpoint at one function and I can see the stack trace. When the breakpoint hits, the windbg shows the source code at current instruction with no problems. But I would like to see the source code at some other address. How can one see the sourcecode at given address like we can with disassembly We use "u "?
What command is for viewing source code? Thanks
.open -a is your friend. If you have yor symbols set up correctly, it will open the source that contains the code at the specified address.
If You have the source code of debugging code why would You like to browse/view it from windbg? Source mode makes debugging very simple but windbg is not a "code browser".
If You want to see the source code at the given address simply check what function "covers" this address e.g.:
kd> uf fffff800`02be05d0
nt!NtOpenFile:
fffff800`02be05b0 4c8bdc mov r11,rsp
...
fffff800`02be05d0 458953e0 mov dword ptr [r11-20h],r10d
Then ctrl-o and open your source code that contains this function(your func ofc unless You work for microsoft :D) and browse it in windbg.

Resources