Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path issue to open disassembly file even after correct configuration #8

Open
pjtallon opened this issue Jun 5, 2019 · 9 comments
Open

Comments

@pjtallon
Copy link

pjtallon commented Jun 5, 2019

Hello,

First of all, thanks for the work on this plugin, this is very helpful to me :)

I am trying to configure the plugin to find disassembly file for any source code and I stumbled on what I think is an issue in the path management of the disassembly files.

Here is my project tree structure :

$ tree -L 2
.
├── build
│   ├── cmake_install.cmake
│   ├── CMakeCache.txt
│   ├── CMakeFiles
│   ├── main.exe
│   ├── main.ii
│   ├── main.s
│   └── Makefile
└── src
    ├── CMakeLists.txt
    └── main.cpp

3 directories, 8 files

And here is my current setup in the workspace settings.json file :

"disasexpl.associations": {
    "**/*.cpp": "${fileDirname}/../build/${fileBasenameNoExtension}.s"
}

Consequently, I would expect the main.s file to be found when pressing F1 -> Disassembly Explorer: Show.

I actually get the following message :

Failed to load file 'd:\<my_project_path_without_HDD_name>\build\main.s'

I suspect the issue to be the name of the HDD, since when I export the file name by right-click on the main.s file, I get the following value :

D:\<my_project_path_without_HDD_name>\build\main.s

I already tried to replace / by \\ in the settings.json file, it changed nothing.

I am running Visual studio code on Windows 10, and I integrated my cygwin bash terminal as the single terminal in Visual Studio Code.

I suspect the HDD letter case to matter as well as the first / as mentionned in #1

Would you have a workaround to provide, eventually ?
Otherwise, I'll wait for a fix :)

I could find #3, but it did not help me since I am using fileDirname instead of workspaceFolder

Best,
Julien

@dseight
Copy link
Owner

dseight commented Jun 22, 2019

Hi,

At first, I'm sorry for a too-late reply.

I've tried exact the same configuration with the same directory layout as yours, but it seems to work well. Maybe there are some other details which can help me to reproduce this behavior?

@pjtallon
Copy link
Author

Hello,

No worries, it's never too late :)

Actually, I tried again just now with the very same setup and things went just fine to access the assembly file.

But, when I tried to slightly change the source code, the assembly file did not get updated.

The tree structure I presented at first is the common structure for all my small projects, which are all located in a C++ folder, located in my current workspace.

I am adding a screenshot of my screen, showing the source code, the project tree structure, the disassembly shown file and the actual .s file that I would like to have a view on.

image

Remark that the add statement does not add the proper offset (1 instead of 5) due to a previous implementation of AddOneTo that used to add one. The file on the very right in the actual AddOneTo.s file I am trying to hgave the disassembly to use.

Hope this helps.
Julien

@dseight
Copy link
Owner

dseight commented Jun 27, 2019

But, when I tried to slightly change the source code, the assembly file did not get updated.

Looks very similar to #6. It seems that fixing that issue will resolve this too.

@pjtallon
Copy link
Author

Indeed, I subscribed to this issue to keep posted and will wait for this fix to test if I still get the issue.
Thanks

@maxdd
Copy link

maxdd commented Dec 13, 2019

I have the same problem, can't find a workaround though.
Tried to change path as well but nothing

@SjoerdNijboer
Copy link

SjoerdNijboer commented Jul 22, 2020

It seems I can only get it to work with absolute paths.
I presumed I could use a relative path from my project root, but I can't get it working on linux.

@yannickowow
Copy link

yannickowow commented Jan 15, 2021

Hi
Did you use it with .S file generated with objdump ?
If so, I did find an issue relating to regexp used to find sourcename/line. It depends of your objdump version, and in my case, it was not working on Windows.

lineRe = /(\/[^:]+):(\d+).*/; // Before
lineRe = /([A-Za-z\/\.][:]*[^:]+):(\d+).*/; // After

With this new regexp, you catch a path with disk name, dot or slash at start.
In the same way, when fetching a new filepath, use path.normalize

And when parsing your document, in Windows, it can be in CRLF format. When processing binary (in processBinaryAsm())

const asmLines = asmResult.split('\n'); // Before
//
const asmLines = asmResult.split('\n').map(str => {
   return str.trimRight();
}); // After

Regards.

@pjtallon
Copy link
Author

Hi
Did you use it with .S file generated with objdump ?
If so, I did find an issue relating to regexp used to find sourcename/line. It depends of your objdump version, and in my case, it was not working on Windows.

lineRe = /(\/[^:]+):(\d+).*/; // Before
lineRe = /([A-Za-z\/\.][:]*[^:]+):(\d+).*/; // After

With this new regexp, you catch a path with disk name, dot or slash at start.
In the same way, when fetching a new filepath, use path.normalize

And when parsing your document, in Windows, it can be in CRLF format. When processing binary (in processBinaryAsm())

const asmLines = asmResult.split('\n'); // Before
//
const asmLines = asmResult.split('\n').map(str => {
   return str.trimRight();
}); // After

Regards.

Hello,
I think I got this output by configuring cmake directly which could be calling objdump or another tool behind the scenes.
Unfortunately, I dropped this problem since then as I'm not making use of the extension on a regular basis : kind of lost context...

Anyway, thanks for your contribution :)

@HorstBaerbel
Copy link
Contributor

I tried using this extension again, and damn it's frustrating, because it looks cool, could be so useful and is sooo close to working oob with CMake. A lot of people here have problems using this with CMake and using compile_command.json might help, as the current "settings.json" options are not enough. This might solve this issue, #13, #20 and get you half-way to #28.

The format of entries in build/compile_command.json is:

{
  "directory": "/home/foo/GameBoy/GBA-image-tools/gba/build",
  "command": "/opt/devkitpro/devkitARM/bin/arm-none-eabi-g++ -DARM4 -D_GBA -I/opt/devkitpro/libgba/include -I/home/foo/GameBoy/GBA-image-tools/gba/../src -I/home/foo/GameBoy/GBA-image-tools/gba -I/home/foo/GameBoy/GBA-image-tools/gba/memory -I/home/foo/GameBoy/GBA-image-tools/gba/video -I/home/foo/GameBoy/GBA-image-tools/gba/print -I/home/foo/GameBoy/GBA-image-tools/gba/sys  -march=armv4t -mthumb -mthumb-interwork -Wl,--wrap=malloc,--wrap=free,--wrap=alloc,--wrap=calloc,--print-memory-usage,--gc-sections,-Map=video.map -save-temps -Wall -Wextra -Wpedantic -mcpu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -fno-aggressive-loop-optimizations -no-pie -fno-stack-protector -fdata-sections -ffunction-sections -std=c++17 -fconserve-space -fno-threadsafe-statics -fno-rtti -fno-exceptions  -march=armv4t -mthumb -mthumb-interwork -Wl,--wrap=malloc,--wrap=free,--wrap=alloc,--wrap=calloc,--print-memory-usage,--gc-sections,-Map=video.map -save-temps -Wall -Wextra -Wpedantic -mcpu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -fno-aggressive-loop-optimizations -no-pie -fno-stack-protector -fdata-sections -ffunction-sections -std=c++17 -fconserve-space -fno-threadsafe-statics -fno-rtti -fno-exceptions -O3 -o CMakeFiles/video.elf.dir/tui.cpp.obj -c /home/foo/GameBoy/GBA-image-tools/gba/tui.cpp",
  "file": "/home/foo/GameBoy/GBA-image-tools/gba/tui.cpp"
},

This gives us:

  • The build directory: "/home/foo/GameBoy/GBA-image-tools/gba/build"
  • The file being compiled: "/home/foo/GameBoy/GBA-image-tools/gba/tui.cpp"
  • The object file subdir it is compiled to: "CMakeFiles/video.elf.dir/tui.cpp.obj"
  • The knowledge that "-save-temps" is being used and .s assembly files should be there.

That information can easily be parsed to auto-generate the .s file name and also run compilation. Build directory and file being compiled are universal information. The rest will depend on the compiler, but most compilers use "-o" for the output file and you can also combine this with the file name. MSVC is special, but making a pretty universal regexp should be easy.

A switch to enable this could be "disasexpl.use_compile_command_json: true", or to check if the project contains a CMakeLists.txt, or if the "C_Cpp.default.configurationProvider" in settings.json contains "cmake".

I'd love to hear what you say about this. I'd love to help, but I've got a few projects already and no idea whatsoever of VSC extension development. If you need beta-testing or a CMake example-project I can help out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants