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

"Pre-comment" does not show in decompiled code view #3940

Open
wothke opened this issue Jan 28, 2022 · 5 comments
Open

"Pre-comment" does not show in decompiled code view #3940

wothke opened this issue Jan 28, 2022 · 5 comments
Assignees
Labels
Feature: Decompiler Status: Triage Information is being gathered

Comments

@wothke
Copy link

wothke commented Jan 28, 2022

Describe the bug
Usually, "pre-comments" seem to show - as expected - in the respective decompiled code view.

I specifically like to use them when I want to put some kind of reminder in the decompiled code so that I will find it again in the exported C/C++ program code.

Unfortunately there seem to be scanarios (the rationale behind which totally escapes me) where respective "pre comments" (or any other comment for that matter) just DO NOT show in the decompiled code view. Usability wise this is a total clusterfuck and I strongly hope that it is just a bug and not by design.

Example:

          *(undefined4 *)((int)&uStack5608 + iVar11) = 0;
          *(undefined4 *)((int)&uStack5608 + iVar11 + 4) = 0xbff00000;

The decompiled code here is obviously acting on a memory location that actually contains a double and what it means to do is: (double)((int)&uStack5608 + iVar11) = -1.0;

To remind me of the respective "todo" to cleanup that code manually later I click on the 1st line and enter a respective "pre comment". Interestingly the comment does show in the corresponding Listing view - where it is absolutely useless to me - but NOT in the decompiled code view:

                             XXX  just a simple "-1.0" assignment to a double
        0040c570 c7 84 3c        MOV                           dword ptr [ESP + EDI*0x1 + 0x674],0x0
                 74 06 00 
                 00 00 00 
        0040c57b c7 84 3c        MOV                           dword ptr [ESP + EDI*0x1 + 0x678],0xbff00000
                 78 06 00 
                 00 00 00 

The mapping from ASM ops to decompiled C statements seems to be rather 1:1 here.. so why does that comment not show in the decompiled code?!

PS: I tried "pre" and "plate" comments on both of the above lines and none of those show in the "Decompile" view - regardless of how many checkboxes I activate in the respective "show comments" preferences..

Expected behavior
Pre-comments should always show in the respective decompiled code view. (or there should be at least some type of comment that always shows - I don't really care). It just sucks not being able to edit ANY comment that will actually show in the decompiled code. Usability wise it should be obvious that when a user clicks in the "decompiled code view" and uses the "Comment ->Set.." functionality, then that functionality should default to something that actually creates a visible comment entry at that selected location!

Environment (please complete the following information):

  • OS: Win10
  • Ghidra Version: 10.1.1
@Pokechu22

This comment has been minimized.

@VioletGiraffe
Copy link

VioletGiraffe commented Apr 8, 2022

I have the same problem with the latest Ghidra release as of the moment of writing. Comments show up in disassembly, but not in the decompiled C code.
Despite enabling all types of comments as suggested above!

@Lainad27
Copy link

Same issue persists through to version 10.3.2.

@Varriount
Copy link

Varriount commented Apr 13, 2024

To add some information to this: I had this happen to a function, then later wiped the project the function was in and re-analyzed everything with a different set of analysis settings. The new project (and newly-analyzed function) accepted my comments.

image

(I had turned off these analyzers because they were finding way too many false positives in the ARM GBA code I was looking at)

@Varriount
Copy link

Some more information: I've had this go away by recreating the function (which I guess forces some sort of remapping/reanalysis).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: Decompiler Status: Triage Information is being gathered
Projects
None yet
Development

No branches or pull requests

7 participants