Community
Participate
Working Groups
Do this: 1. Start debugging a program. 2. Stop some functions down into the stack. 3. Select a stack frame that has no source code associated with it. 4. Enable assembly view. Current result: * A bunch of instructions (30?) starting at the current instruction pointer are displayed, regardless of which ones belong to the current function or not. Expected result: * If the function boundaries are known, assembly for the whole function should get displayed, and not anything else. Since in my case addresses are decorated with the offset from the function's starting address, in my case the function boundaries are known, and this is what I should have had to view.
For debugging a memory location that GDB knows nothing about, see bug 27239.
This is partially fixed. Now the Disassembly view displays only the instructions that belong to the current function. But the first instruction of the view is the current instruction pointer not the first instruction of the function (as it should be). The problem is that GDB/MI "data-disassemble" command unlike GDB/CLI "disassemble" accepts only file name and line number or start address and end address as arguments.
According to the GDB/MI docs (and my own experiments), GDB/MI supports ordinary GDB commands as well. I can't say how well this will be supported in future GDB releases or anything, but you can actually say "disassemble foo" and get all of foo() disassembled. This feels kind of hackish to me, but it could solve the problem.
Actually, I just discovered you get different output from "disassemble" and "-data-disassemble", so depending on how you parse stuff that may not be a solution after all.
LATER/REMIND are deprecated. Changing to reopened milestone '--'
The current disassembly view is infinite if scrolled up and down. Marking resolved.
