From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30865 invoked by alias); 7 Jun 2009 14:48:22 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 30856 invoked by uid 22791); 7 Jun 2009 14:48:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Date: Sun, 07 Jun 2009 14:48:00 -0000 From: Jan Kratochvil To: Joost van der Sluis Cc: archer@sourceware.org Subject: Re: Calculating array length Message-ID: <20090607144745.GA21154@host0.dyn.jankratochvil.net> References: <1244370173.22994.14.camel@wsjoost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1244370173.22994.14.camel@wsjoost> User-Agent: Mutt/1.5.19 (2009-01-05) X-SW-Source: 2009-q2/txt/msg00145.txt.bz2 On Sun, 07 Jun 2009 12:22:53 +0200, Joost van der Sluis wrote: > But I also have a lot of questions, I hope this is the right place for > them. Yes, VLA support is currently still not integrated with FSF GDB. > First question is the calculation of the length of an array-type in > type_length_get(), gdbtypes.c. (I'm using the archer-jankratochvil-sla > branch to improve the handling of arrays) > > The length is calculated as follows: (count-1)*byte_stride+element_size. > > Ok, so why 'count-1'? Count is the actual item-count, why substract it > with one? And why is the element_size added? byte_stride (when defined) > should replace the element_size? > > It doesn't make sense to me, as it should be: 'count*byte_stride'? It depends which length do you want to calculate. According to what you describe you want to set the FULL_SPAN parameter of type_length_get to be true. Then it will really return 'count*byte_stride'. Still the function uses FULL_SPAN as true only internally. When GDB wants to know the type length it uses it for transferring data from the debuggee memory into a local GDB copy (for its printing to the user etc.). For such case we want a _minimal_ (but still complete) contiguous memory range. Fortran example: subroutine sub (p) integer :: p (2, 1) print *, p (1, 1) print *, p (2, 1) end subroutine sub program subarray integer :: a (2, 2) a (1, 1) = 1 a (1, 2) = 2 a (2, 1) = 3 a (2, 2) = 4 call sub (a (1:2, 2:2)) end Array `a' in the main program has layout (here the first index is row, second one is column): 1 2 3 4 X Y (these are uninitialized / nonexisting / unused memory locations after the end of array) Subroutine `sub' will print: 2 4 Subroutine `sub' know only about a table with 2 rows and 1 column. To make it working with the original array `a' memory layout without any copy the pointers to the array are setup as: array start: row 1 column 2 (element content `2') rows, therefore number of elements of p: 2 columns, therefore number of elements of p row: 1 element size of p (one row byte length): sizeof (integer) * 1 element size of p row (one element byte length): sizeof (integer) byte stride of p (offset to the next row): sizeof (integer) * 2 byte stride of p row: sizeof (integer) Now if you in `sub' do `print p' GDB has to transfer the `p' memory from inferior. Currently it will transfer contiguous block with content {2,3,4}. If we would always use FULL_SPAN true then GDB would transfer in this case a contiguous memory block with content {2,3,4,X}. But X is after the end of the array and for very large arrays (thousands of elements or elements of size in kilobytes) memory for X may no longer be mapped and GDB would fail retrieving the memory of variable being wished to be printed. (+It would be also less effective.) GDB has to transfer only the memory it knows that belongs to a variable. Regards, Jan