Review of 64-bit support in source debugger window

Review of 64-bit support in source debugger window

[Kris Van Hees]

As discussed on the conf calls, I undertook an in-depth review of the
state of 64-bit support in the source debugger window (specifically, the
register, memory, and disassembly windows).  Andrew reported that 64-bit
support works, and that the memory and disassembly windows were still
disabled as an oversight rather than an indication of not working.  But
since the current state was reported as 'works until proven otherwise'
and given that there aren't really tests for this GUI functionality, it
seemed sensible to further investigate the situation.

The low level code definitely seems robust, and working well.  The only
potential issue I found there was the fact that there does not seem to
be any verification on addresses passed into the ptrace code to peek at
memory locations.  The ptrace implementation does this at the kernel
level, of course, but it seems prudent to avoid calling system calls
with addresses that are known to be outside the valid range.  There may
be other obscure issues, but I haven't found any.  I focused mainly on
the GUI-level code for this investigation.

I marked issues as either [BUG] or [HCI].  If it marked [BUG] my
interpretation of the issue is that it is a true bug in the code.  If it
is marked [HCI] it is more of a user interaction issue, evaluated based
on common user interaction practises, the Design-for-All principle, and
current research in the HCI field.

Register Window
---------------
Seems to work correctly.

Memory Window
-------------
 1. [BUG] Spin buttons for address range have an incorrect upper bound.
 2. [HCI] Spin buttons do not allow entry of specific values.
 3. [BUG] Spin buttons allow addresses outside the valid address range.
 4. [HCI] There is no way to know what address ranges are valid for the task
	  being debugged.
 5. [HCI] There is no way to know what address spaces are available for
	  examination (goes together with 4).
 6. [BUG] Default number of bits is 32, even on a 64-bit platform.
 7. [BUG] When selecting number of bits as 64, column still states '32-bit
	  Hexadecimal (LE)' even though it truly does show 64-bit values in the
	  column.
 8. [HCI] Hexadecimal values are shown without leading zeros, making for a
	  rather messy, difficult-to-read display.
 9. [BUG] Changing the columns to be displayed using the 'Edit Columns' button
	  does not result in a change in the window.  Closing and re-entering
	  does not make a difference.  Changing the address range using the
	  spin buttons, or changing the number of bits, does cause the new
	  selection for columns to be applied.
10. [HCI] At top of window "Current program counter' is displayed which is not
	  appropriate for a memory examination window where we should be able
	  to examine data segments as well.
11. [HCI] The current program counter value is displayed in hexadecimal and in
	  decimal, using widgets that appear as text field, yet you cannot
	  change the value.  That is confusing.
12. [BUG] Performing a right-click on the 'down' From spin button causes a
	  endless stream of 'null' to be written to the terminal where FryskGui
	  was started (each on its own line).  Only way to stop Frysk is Ctrl-Z
	  + kill.
13. [BUG] Performing a right-click on the 'up' To spin button causes FryskGui
	  to hang without any output.  Only way to stop Frysk is Ctrl-Z + kill.

Disassembly Window
------------------
 1. [HCI] The greyed out 'Edit Columns' button makes it seem like there is a
	  way to enable it (and if there is, I haven't found it yet).  Perhaps
	  better to simply not have it there.
 2. [BUG] It is not possible to increase either the From or To addresses using
	  the spin buttons, making it impossible to obtain a disassembly of
	  code before and after the displayed range.
 3. [BUG] Performing a left-click on the 'down' From spin button causes
	  FryskGui to hang without any output.  Only way to stop Frysk is
	  Ctrl-Z + kill.
 4. [BUG] Performing a left-click on the 'down' To spin button causes the
	  address to be set to the value of the From spin button rather than
	  performing e.g. a decrement.
 5. [BUG] Spin buttons for address range have an incorrect upper bound.
 6. [HCI] Spin buttons do not allow entry of specific values.
 7. [HCI] The current program counter value is displayed in hexadecimal and in
	  decimal, using widgets that appear as text field, yet you cannot
	  change the value.  That is confusing.