From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28881 invoked by alias); 9 Jun 2007 17:57:25 -0000 Received: (qmail 28872 invoked by uid 22791); 9 Jun 2007 17:57:24 -0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME X-Spam-Check-By: sourceware.org Received: from agminet01.oracle.com (HELO agminet01.oracle.com) (141.146.126.228) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 09 Jun 2007 17:57:21 +0000 Received: from rgmsgw01.us.oracle.com (rgmsgw01.us.oracle.com [138.1.186.51]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l59HvI0t019399 for ; Sat, 9 Jun 2007 12:57:18 -0500 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmsgw01.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l59HvHBq020559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jun 2007 11:57:18 -0600 Received: from kvanhees by ca-server1.us.oracle.com with local (Exim 4.63) (envelope-from ) id 1Hx5Bd-0003bt-8F for frysk@sourceware.org; Sat, 09 Jun 2007 10:57:17 -0700 Date: Mon, 11 Jun 2007 16:25:00 -0000 From: Kris Van Hees To: frysk@sourceware.org Subject: Review of 64-bit support in source debugger window Message-ID: <20070609175716.GF9467@ca-server1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00254.txt.bz2 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.