Skip to content

Conversation

@LagoLunatic
Copy link
Collaborator

This adds a text field to the function diff view that lets you type a line number in and be automatically scrolled to the first asm line that corresponds to that line of source code. This can be useful for very large functions so you don't have to manually scroll through thousands of lines of asm to find what you're looking for:
image
image

Also added a Ctrl+G shortcut to focus the text field. (You don't need to press the shortcut for the scrolling to start happening, it just takes whatever you typed and starts scrolling to it immediately.)

If line info is disabled of course it doesn't do anything. Also, I didn't implement this for the left side, just the right side (in both joint and split view). Not sure if this would ever be useful for the left side.

@tomsons26
Copy link
Contributor

Not sure on the visual aspect but perhaps goto offset to go along with it?
Maybe on target asm plane?

@LagoLunatic
Copy link
Collaborator Author

What's the specific use case for goto offset? Line numbers you can see in the source file. Where will you see an offset outside of objdiff and want to quickly jump to that offset in the function within objdiff?

@LagoLunatic
Copy link
Collaborator Author

Oh maybe switch statement jump tables? objdiff doesn't really show those very well so every once in a while you have to look at the addends for each case and fix the function cases to match those offsets manually.

Might be worth having but it could look cluttered to have another text field for that. Would it be too confusing if they shared a field and 124 jumped to line 124 but 0x124 jumped to offset 0x124?

@dbalatoni13
Copy link
Contributor

Maybe a "go to virtual address" would be useful sometimes

@LagoLunatic
Copy link
Collaborator Author

Maybe the goto field could distinguish between them like this?

  • line:1234
  • offset:124/offs:124
  • address:80123478/addr:80123478

@LagoLunatic LagoLunatic marked this pull request as draft December 31, 2025 18:11
@tomsons26
Copy link
Contributor

tomsons26 commented Jan 1, 2026

What's the specific use case for goto offset? Line numbers you can see in the source file. Where will you see an offset outside of objdiff and want to quickly jump to that offset in the function within objdiff?

I am not referring to the current view.
You don't have line numbers in target

Say i need help with a specific chunk, i tell what target offset that chunk is at to who've ever im requesting assistance.
As is, in a large function that's a lot of scrolling and squinting.

Additionally something to note, line numbers aren't always reliable, due to various technicalities line numbers aren't always correct, for example, in MSVC targets objdiff shows end of function line numbers on inlines when it can't read inline line numbers, if it can read inline line numbers it shows those not the inline's call site line numbers

In other words, if it can resolve a inline line number
1542: i++;
1543: DoThing(i);//function in thing.h line 34
1544: return i;
Becomes
1542: i++;
34: if (i == 252) {
35: i = 0;
36: }
1544: return i;

If it can't

1542: i++;
1544: if (i == 252) {
1544: i = 0;
1544: }
1544: return i;

I haven't deep dived into this problem, it's probably fixable but it shows that line numbers may not always work right

@tomsons26
Copy link
Contributor

Maybe the goto field could distinguish between them like this?

  • line:1234
  • offset:124/offs:124
  • address:80123478/addr:80123478

If its one field then probably 0x for offset as suggested earlier, not sure what to do on address...
Alternatively provide a dropdown where you select the type, objdiff should remember the choice however to not become annoying

@LagoLunatic
Copy link
Collaborator Author

I guess there should be one text field on each side then. Since having the right side one navigate based on values from the left side would be confusing, and you want to navigate based on the left side's offsets.

Additionally something to note, line numbers aren't always reliable

I'm aware, but for MWCC at least line numbers seem reliable as long as nosyminline on isn't used. I'm not going to look into improving line number parsing for this PR, for now it's just a matter of using this feature for projects where line numbers are accurate and not using it in projects where they're inaccurate. You can open a separate issue to track issues with the line numbers themselves if you want.

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

Successfully merging this pull request may close these issues.

3 participants