From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12771 invoked by alias); 15 May 2010 21:44:35 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 12759 invoked by uid 22791); 15 May 2010 21:44:34 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Sat, 15 May 2010 21:44:00 -0000 From: Jan Kratochvil To: Joost van der Sluis Cc: Project Archer Subject: Re: Patch for pascal-dynamic arrays Message-ID: <20100515214421.GA9965@host0.dyn.jankratochvil.net> References: <1256751286.31305.24.camel@wsjoost.cnoc.lan> <20091030094726.GA29758@host0.dyn.jankratochvil.net> <1257630529.27675.26.camel@wsjoost.cnoc.lan> <1271071502.27845.15.camel@wsjoost.cnoc.lan> <20100412195106.GA32767@host0.dyn.jankratochvil.net> <1271241292.21465.18.camel@wsjoost.cnoc.lan> <20100506230504.GA21919@host0.dyn.jankratochvil.net> <1273874250.9996.33.camel@wsjoost.cnoc.lan> <20100514224613.GA3338@host0.dyn.jankratochvil.net> <1273955042.32006.31.camel@wsjoost.cnoc.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273955042.32006.31.camel@wsjoost.cnoc.lan> User-Agent: Mutt/1.5.20 (2009-08-17) X-SW-Source: 2010-q2/txt/msg00024.txt.bz2 On Sat, 15 May 2010 22:24:02 +0200, Joost van der Sluis wrote: > But it works great. Thanks, checked-in as: b468b41f5c4cf1a5a55fc33402ce4695ace3579c > Take a look a this bug-report > (http://sourceware.org/bugzilla/show_bug.cgi?id=11492) about the > identification of arrays. It has a better fix for that, and it avoids > problems when merging this later. OK, removed that part from the patch above. It will get merged again only with new FSF GDB HEAD anyway. > And when you do a 'print s' when the breakpoint is before line 80. (In > arrays.pas) you get 'Object is not allocated'. In theory this is true, > but unallocated strings in pascal are handled as empty strings (''). But > that's a minor issue that's fixable in p-valprint only. 33:var StatArrInt: TStatArrInt; 44: s: string; 48:begin 80: s := 'test'#0'string'; I believe In such case the DWARF data should not use DW_AT_allocated at all. <1><255>: Abbrev Number: 21 (DW_TAG_array_type) <256> DW_AT_name : AnsiString <261> DW_AT_data_location: 2 byte block: 97 6 (DW_OP_push_object_address; DW_OP_deref) <264> DW_AT_allocated : 2 byte block: 97 6 (DW_OP_push_object_address; DW_OP_deref) <267> DW_AT_type : <0x437> <2><26b>: Abbrev Number: 22 (DW_TAG_subrange_type) <26c> DW_AT_lower_bound : 1 <26d> DW_AT_upper_bound : 5 byte block: 97 6 38 1c 6 (DW_OP_push_object_address; DW_OP_deref; DW_OP_lit8; DW_OP_minus; DW_OP_deref) In the case of Fortran the runtime crashes (on a NULL dereference) while accessing non-allocated object. But if the "allocation" is just an internal compiler issue which should be hidden by the same compiler at the DWARF level. Therefore I would guess to use some: drop DW_TAG_array_type -> DW_AT_allocated DW_TAG_subrange_type -> DW_AT_upper_bound: DW_OP_push_object_address DW_OP_deref DW_OP_dup DW_OP_bra allocated DW_OP_lit0 DW_OP_skip end allocated: DW_OP_lit8 DW_OP_minus DW_OP_deref end: > The next challenge is to print individual items from the array. (print > DynArrStr[3]). But that didn't work with my patch either. And I think > that with your solution it's easier to implement this. $1 = {'dstr0', 'dstr1', 'dstr2', 'dstr3', 'dstr4', 'dstr5', 'dstr6', 'dstr7', 'dstr8', 'dstr9', 'dstr10', 'dstr11', 'dstr12'} $2 = '?`???'#127#0#0'0a??' OK... hopefully some new similar patch would work. Thanks, Jan