From: Kris Van Hees <kris.van.hees@oracle.com>
To: frysk@sourceware.org
Subject: Review of 64-bit support in source debugger window
Date: Mon, 11 Jun 2007 16:25:00 -0000 [thread overview]
Message-ID: <20070609175716.GF9467@ca-server1.us.oracle.com> (raw)
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.
reply other threads:[~2007-06-09 17:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070609175716.GF9467@ca-server1.us.oracle.com \
--to=kris.van.hees@oracle.com \
--cc=frysk@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).