Disassembly view showing wrong instructions #935
Comments
Don't know what you mean by correct order? They are ordered by addresses as returned by GDB. We don't do our own disassembly. But we create the requests (which could be wrong) to gdb to do the work. You can use gdb from the Debug Console to print the disassembly to see what you get for an address range, and does it match what is in the disassembly window. And, does it make sense? |
|
The initial currenty highlighted line is where your |
|
Look at the addresses on the left side (1st screenshot), they should be increasing monotonically. 0x82d2 The |
|
We are expecting instructions in sorted order as well. Can you do the following?
|
|
I used the start and end addresses by looking at what was in the Debug Console at the time. If your program has changed, please adjust the |
|
I'm using GCC for ARM. Why would you think otherwise? I tried your suggestion: I'm using a simpler project now to make debugging easier, hence the different code and addresses. But considering that the output of the
|
|
After hooking the extension up to the debugger, I'm starting to think this may be a bug in VS Code, since I couldn't find anything going wrong in the extension. And when I look at the DOM of the Disassembly view, I can see a mismatch between the |
|
Good detective work! It is still possible that we are doing something wrong. Let us verify that we are sending VSCode a proper response. VSCode is not supposed to interpret what we send or do so minimally. If you put the following in your launch.json, we may be able to see what VSCode requested and what we returned. It should also match the manual disassembly you have done.
When you say that are you actually single-stepping in the extension within VSCode or using the Chrome Debug tools to examine the DOM? |
Because I saw the |
|
Here you go: I'm not sure what to make of this though. Yes, I was setting breakpoints and stepping through the extension code and when I checked e.g. the I examined the DOM with Chrome Debug tools in addition to that, but I don't know how to debug the client-side/UI code. I'm trying to build VS Code from source now, but it's giving me a headache 😖 I guess this project is using the |
|
Heheh. Yes, building VSCode is a challenge, but hopefully we don't need that. Lines starting with Since you are already debugging this extension, could you do the following.
You can If you make any changes and re-compile, make sure you completely restart the second VSCode instance. You also have to terminate all debug sessions in the first instance before you restart. |
|
Unfortunately, VS Code is truncating everything that is too large, so this method didn't help. But I found out I can copy the response to the clipboard using Here's the output: https://gist.github.com/gietljohannes/710e0e4d8522d8ab9586f460eb37f380 I also used this code snippet to check if all addresses are in order (they are): Maybe the problem lies in this file ? https://github.com/microsoft/vscode/blob/b30900b56c4b3ca6c65d7ab92032651f4cb23f15/src/vs/workbench/contrib/debug/browser/disassemblyView.ts |
|
Aaaarghhh. I would like to not go into the VSCode code base. In this case, I know who authored it, he may accept a PR. But, it is still hard to believe that the problem is in VSCode because they don't interpret anything other than the I will review the VSCode implementation tomorrow maybe. |
|
also see this issue w/ v1.12.1, preventing any debug-attempt at assembly-level :( |
|
I might have just ran into this. I use objdump to dump source code: Using Cortex-debug I look at addres 00324 an I see different source files. This is with 1.12.1 and kind of makes the cortex-debug useless as that it shows the wrong source code when stepping through code. |
|
@trampas Not sure what is different/wrong. At 0x324, I see the same stuff from the screenshot vs some text you pasted (guess the output of objdump). I am missing something Btw, we have to use gdb to disassemble and you can see the gdb requests and what it returns in the Debug Console if you enable debug -- see what other users did above |
|
In the image, address 32a is showing different source files. The left list is from objdump, the right is the cortex-debug disassemble which shows address 32a being from I2C master file which is incorrect. The assembly is the same but when stepping through code cortex-debug steps through wrong source file. |
|
Like I said, we rely on GDB. We don't disassemble or calculate source locations. Objdump and gdb may not use the same algorithm either. In your objdump output in the screenshot (right side I guess), I don't see any source information at all. I see some comments that are offsets to other symbols, but that is not source information. Can you use gdb commands to do the disassembly. That is the one I trust. and the only one we can rely on. https://visualgdb.com/gdbreference/commands/disassemble You can enter gdb commands at the bottom of the Debug Console... Also, we don't step through. We ask gdb to do it and it reports back when/where the next stop happens. We are not a debugger. We are a front end to a real debugger like GDB. |
|
Left be is objdump, right is from cortex-debug disassembly. I will see if I can figure out why gdb is not correct. |
|
After much work I found that arm-none-eabi-gcc version 10.3.1-2.2.1 works and shows the correct source files. While version 11.2.1-1.1.1 or later versions all have an issue where the source code shown in disassembly or when stepping through files is incorrect. |
|
I loaded up 11.2.1-1.1.1. I opened the disassembly in vscode. 
I do not do much with the gdb on the command line and not sure what gdb commands are used to show the source files and disassembly, but something seems wrong. Note that I have multiple versions of gdb on my computer, and was wondering if cortex-debug/vscode was using one from path? I do have the following set in the launch.json |
|
I have also noticed when I use 10.3.1 toolchain, I can not toggle the disassembly view, not sure why. I also dumped the cortex-debug log for both configurations if it helps anyone. |
|
The disassembly view and source code toggling is handled by VSCode https://github.com/Marus/cortex-debug/wiki/Disassembly-Debugging |
|
I have found that the 10.3.1 11.2.1 |
|
I have done some looking and it does appear to be a arm-non-eabi-xxx issue. I am trying to track down the correct place to post the issue now. From what I can figure out. My code has a lot of unused functions, basically I included all the drivers and libraries and main() does very little at the moment. From what I can figure out there was some changes in gcc for -flto in gcc 11. With these changes the elf file contains all the unused function symbols, and the assumes they all exists at address 0. I am not sure how gdb picks which function to assume is the one running, but seems to get it wrong sometimes. This is why when I step through my code it goes to random functions. |
Describe the bug
When a breakpoint is hit in an editor window, and the user opens the disassembly view, the addresses, offsets and instructions there are all mixed up, meaning in the wrong position. Some instructions are usually in the right place, but then there are seemingly random addresses from other locations of the program text intertwined. Some instructions are even in the wrong order (meaning higher addresses appear above lower addresses and vice versa.
After scrolling a page up or down and then back to the current (highlighted) instruction, the disassembly view is reset to showing all the right instructions again as expected.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
All lines of the disassembly are in the correct order.
Screenshots
Before scrolling: (notice even the current, highlighted instruction is incorrect)
After scrolling:
Environment (please complete the following information):
Please include
launch.jsonNote: We are unlikely to look at the issue if you do not supply this
Attach text from
Debug ConsolePlease enable debug output in your launch.json (
"showDevDebugOutput": "raw"). It this is too large, please attach it as a fileAdditional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: