From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27516 invoked by alias); 28 Sep 2012 17:32:40 -0000 Received: (qmail 27508 invoked by uid 22791); 28 Sep 2012 17:32:39 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Sep 2012 17:32:35 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8SHWY52018557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Sep 2012 13:32:34 -0400 Received: from host2.jankratochvil.net (ovpn-116-94.ams2.redhat.com [10.36.116.94]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q8SHWUcR013855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Sep 2012 13:32:33 -0400 Date: Fri, 28 Sep 2012 17:32:00 -0000 From: Jan Kratochvil To: gdb@sourceware.org Cc: Siddhesh Poyarekar Subject: 64-bit (>4GB) inferior data types rules; TYPE_LENGTH: unsigned -> ULONGEST Message-ID: <20120928173229.GA10406@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00079.txt.bz2 Hello, original problem - GCC produces working >4GB data types code while GDB cannot handle them: [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct http://sourceware.org/ml/gdb-patches/2012-02/msg00403.html There should be checked in soon thanks to Siddhesh Poyarekar an extension of TYPE_LENGTH from 'unsigned int' to ULONGEST: [PATCH 0/4] bitpos expansion summary reloaded http://sourceware.org/ml/gdb-patches/2012-09/msg00628.html Anything checked-in since the following commit would be great to no longer break this goal to handle it correctly: http://sourceware.org/ml/gdb-cvs/2012-09/msg00161.html commit cec90d9d386f57f116e114c50e4287281420f531 Author: siddhesh Date: Thu Sep 27 10:39:58 2012 +0000 * amd64-tdep.c (amd64_return_value): Revert previous change that used TYPE_LENGTH directly. [...] * vax-tdep.c (vax_return_value): Likewise. So far GDB was freely using 'int' for any inferior sizes. This is no longer compatible, use always wide enough types: (1) signed vs. unsigned types do not matter for inferior data types sizes. Such as LONGEST vs. ULONGEST or ssize_t vs. size_t. GDB will never successfully allocate more than 2GB on 32-bit host (size_t max larger than ssize_t). And it does not make sense to consider anyhow sizes above 9 quintillion (ULONGEST max larger than LONGEST on any host or size_t larger than ssize_t on 64-bit hosts). (2) Use the smallest valid type, therefore use size_t/ssize_t for objects present in host GDB memory - not LONGEST/ULONGEST. On 32-bit hosts it cheaper and also IMO the code is more readable with appropriate types. BTW for size_t/ssize_t format string is "%z". Also use CORE_ADDR where appropriate, GDB was also using sometimes incorrectly LONGEST/ULONGEST instead. BTW for CORE_ADDR format string is "%s", paddress (gdbarch, X). BTW for LONGEST/ULONGEST format string is "%s", plongest (X) or "%s", pulongest (X) accordingly. Never use long / unsigned long (it is host platform dependent). (3) For allocating inferior data in host GDB memory, therefore assigning LONGEST/ULONGEST (type of TYPE_LENGTH) to size_t/ssize_t variable: One needs to manually check the value fits in. Call ulongest_fits_host_or_error for that. It will ensure the size <= SIZE_MAX / 8 so even small additions after the check will not overflow the type before it gets passed to xmalloc. (4) Copying >2GB inferior data to host memory is probably unreal. In reality GDB should copy the data on-demand. But that is a future patch outside of the scope of this patchset. IIUC such patch will be at least easier to write when the code already knows the valid 64-bit size of the inferior object. Still it is currently more correct to "lock up" GDB (interruptible by CTRL-C) than to respond to user with invalid/shortened data without printing any error. (5) Patched GDB expects only these inferior types may have >2GB size: TYPE_CODE_ARRAY, TYPE_CODE_STRUCT, TYPE_CODE_UNION And of course where applicable: TYPE_CODE_TYPEDEF While a compiler may create <1><57>: Abbrev Number: 3 (DW_TAG_base_type) <58> DW_AT_byte_size : 0x123456789 <59> DW_AT_encoding : 5 (signed) <5a> DW_AT_name : veryhugeint it is OK GDB will not internally handle it correctly, not giving any error. There could be a new patch to reject such types in dwarf2read.c on read-in. (6) If a function is called only for small inferior types (scalars) then it is OK to have there / keep there 'int' type for the inferior type size. Callers have to ensure array/struct/union type cannot be passed there. If a function does gdb_assert (length < 16); then sure it should not happen - it is an assert. But still one needs to keep the 'length' parameter as LONGEST/ULONGEST so that the assert makes sense. Thanks, Jan