Fixed #267 #268
Fixed #267 #268
Conversation
|
@2vg thank you for the patch! LGTM, looks like rustfmt failed, can you run it on that file? thanks, once CI passes can merge |
| @@ -227,11 +227,12 @@ impl<'a> SyntheticImportDirectoryEntry<'a> { | |||
| opts, | |||
| ) { | |||
| debug!("Synthesizing lookup table imports for {} lib, with import lookup table rva: {:#x}", name, import_lookup_table_rva); | |||
| let import_lookup_table = SyntheticImportLookupTableEntry::parse::<T>( | |||
| let import_lookup_table = SyntheticImportLookupTableEntry::parse_with_opts::<T>( | |||
There was a problem hiding this comment.
@ko1N since you implemented this feature, does this look correct to you?
There was a problem hiding this comment.
I don't know why not passing the opts along would hurt, and seems to resolve @2vg 's issue (though I confess I'm not sure what was the exact problem), so I assume this is ok :)
There was a problem hiding this comment.
Yes, the table entry will not be resolved properly when not passing the opts in case rva_resolve is disabled.
Since we left all regular parse functions untouched (as in the regular/"old" behavior) this was an oversight on my part. Luckily those changes could've only caused trouble when using mapped binary dumps. Either way, the change look totally fine to me.
|
@2vg thank you for your patience, merged; would you like a new release? I will likely add this to the 0.4 release, which has one (minor) breaking change, but which should not affect your usecase at all (PE, iiuc) |
|
Ok 0.4.0 is out :) |
related: #267
The problem here was solved by using parse_with_otps.
I had some time, so I debugged and confirmed that the problematic code I presented didn't cause any problems.
No tests were added because I didn't have time to write the tests.
If you have time, please help me :<