Another long delay in updates as I’ve spent so much time on fixing one simple
problem. The problem of jump tables being added to the end of objdump files.
There was a lot of detective work in gdb that I don’t have anything tangible to
show for the time spent. The amount of code needed to solve the problem was
minimal. As with all the other phases of the project I’ve spent most of my time
figuring out how the pieces of the puzzle fit together and reading other peoples
code. This may be just the nature of large coding projects, as opposed to small
college projects where a lot of code is written and there is no interaction
with existing code.
INFO messages, that were once error messages, would appear showing size
mismatches in the same symbols from different exe’s.
They were mostly about block01.exe and base_sp.exe being matched with other
exe’s. So I would pair those with other exe’s and try and produce just just one
instance of the INFO message and then examine the objdumps and compare the
symbols with the discrepancies.
As can be seen above a jump table is added to the symbol
TOD_TICKS_PER_SECOND_method in fsrfsbitmap01.exe which creates the byte
size discrepancy as the code that is processing this is looking for the next
symbol to start to finalise the current symbol as the (new symbols address - 1).
The other processing statement detects regular instruction lines from the body
of a symbol.
The problem was to come up with a check that was restrictive enough to catch all
jump tables but not too retrictive that it cuts symbols short. It looked as if
checking just for ‘__end’ would be good enough and it did chop the jump tables
at the correct location but I later realised that the branch information had
disappeared in the report. It must have been too loose and chopping lines up in
other places as well.
There were also other jump tables that didn’t have this structure so what ended
up being universal was ‘call’ and ‘+0x’ were all found in all tables. Along with
the normal checks for an instruction line, if all 5 were found it was a jump
table. The symbol could then be finalised as normal. We also needed to set
processSymbol = false, which keeps track if we are in the middle of a symbol
or finished with it. Then along with the 5 items checked, we check processSymbol
to make sure only one line of the jump table is processed and then nothing is
done until a new symbol starts again.
The solution consists of this scanning check for the five items mentioned.
and then the multiple check if statement which looks complicated but it’s as
simple as I could get it.
In the end the solution was simple enough but there was a lot of sleuthing in
gdb checking variables, following the program around and many, many iterations
of the above solution that did not work.
All error messages are cleared up now and I’ve gone through a quick code review
with simple changes that I implemented. A more in depth second review of which
I have fixed all issues, one of the major blockers here was the use of symlink
and copying files as the methods are not portable with Linux, BSD and Windows.
I’m working on a third review at the moment, some of which are large changes
that will have to be implemented post-GSOC. I’m hopeful that the critical
changes are doable in the time left and the code will get merged soon.