Page 2 of 4
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Tue Dec 20, 2016 3:14 pm
by Josef Templ
I have fixed the utf-8 conversion for procedure names.
For the diffs see
http://redmine.blackboxframework.org/pr ... 38f8d9c26c.
I also removed unused constants in DevBrowser from issue-#140 that happend to
reappear after a manual merge conflict resolution.
(I also removed a couple of commented debug statements.)
I did not have time to look closely into the fixup chains.
(My first impression is that it is not easy to make the decoder
a symbolic disassembler that outputs symbolic names where possible.
It is also not easy to identify the places that may benefit from a comment like "fixup".
There is already a lot of symbolic information by means of merging the decoded instructions
with the source code. For understanding the output of the compiler's code generator this
is sufficient for me.)
- Josef
- Josef
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Fri Dec 23, 2016 6:37 pm
by Ivan Denisov
Checked this version:
http://blackboxframework.org/unstable/i ... a1.751.zip
Utf8 procedures are shown correctly now.
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Fri Dec 23, 2016 6:41 pm
by Ivan Denisov
Josef Templ wrote:
Instructions that need fixups can not be displayed "correctly" because the fixups are done
after loading the module. They refer to addresses only known at runtime, that's why
they need to be "fixed up" by the loader.
The only thing that may be possible in some cases is to add the target as a comment.
With the source merge feature, however, you see the target anyway from the source.
Can you please add this comment, that "this address is shifted by the fixup during the module load"? Or something like this...
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Thu Feb 23, 2017 9:13 am
by Ivan Denisov
Josef, do you think that this address problem does not require comments? There should be some documentation explanation anyway. DevDecoder386 does not have any documentation now!
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Mon Feb 27, 2017 10:12 am
by Josef Templ
The docu could be added to DevBrowser.ImportCodeFile.
BTW, the docu of DevBrowser.ShowCodeFile is inconsistent because ShowCodeFile
does not support filtering when a qualified identifier is selected.
By adding the docu to DevDecoder386 it will be hard to find for users.
However, a DevDecoder386 docu stub for "internal module" should be added indeed.
- Josef
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Wed Mar 08, 2017 9:08 am
by Josef Templ
The docu has been improved as proposed by Ivan.
Please review.
see changes at
https://redmine.blackboxframework.org/p ... b291b9b0fb
- Josef
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Sat Mar 11, 2017 6:48 pm
by Robert
It looks like we should vote on incorporating these changes.
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Sun Mar 12, 2017 2:04 am
by Ivan Denisov
Robert wrote:It looks like we should vote on incorporating these changes.
Agree. With documentation it looks finished.
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Mon Mar 13, 2017 9:12 pm
by Robert
Does it make sense to vote on an issue that is not open? Do we need a new issue, or can this be reopened?
I'm not sure of the process here.
Re: issue-#142 adding a disassembler to the ocf importer
Posted: Tue Mar 14, 2017 4:56 am
by Ivan Denisov
Robert wrote:Does it make sense to vote on an issue that is not open? Do we need a new issue, or can this be reopened?
I'm not sure of the process here.
I think, we can reopen it before voting.
I changed status to resolved:
https://redmine.blackboxframework.org/issues/142