public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Joost van der Sluis <joost@cnoc.nl>
Cc: Project Archer <archer@sourceware.org>
Subject: Re: Patch for pascal-dynamic arrays
Date: Sat, 15 May 2010 21:44:00 -0000	[thread overview]
Message-ID: <20100515214421.GA9965@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <1273955042.32006.31.camel@wsjoost.cnoc.lan>

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

  reply	other threads:[~2010-05-15 21:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14 14:45 Joost van der Sluis
2009-09-16 15:45 ` Jan Kratochvil
2009-09-16 18:18   ` Joost van der Sluis
2009-09-16 18:41     ` Jan Kratochvil
2009-09-16 19:09       ` Joost van der Sluis
2009-09-30 16:00   ` Joost van der Sluis
2009-10-04 14:17     ` Jan Kratochvil
2009-10-05 10:08       ` Joost van der Sluis
     [not found]       ` <1254737231.3257.20.camel@wsjoost.cnoc.lan>
2009-10-05 14:43         ` Jan Kratochvil
2009-10-28 17:35       ` Joost van der Sluis
2009-10-30  9:47         ` Jan Kratochvil
2009-11-07 21:49           ` Joost van der Sluis
2010-04-12 11:25             ` Joost van der Sluis
2010-04-12 19:51               ` Jan Kratochvil
2010-04-14 10:35                 ` Joost van der Sluis
2010-05-06 23:05                   ` Jan Kratochvil
2010-05-14 21:58                     ` Joost van der Sluis
2010-05-14 22:46                       ` Jan Kratochvil
2010-05-15 20:24                         ` Joost van der Sluis
2010-05-15 21:44                           ` Jan Kratochvil [this message]
2010-05-16 12:04                             ` Jonas Maebe
2010-05-16 17:06                               ` Joost van der Sluis
2010-05-16 17:31                                 ` Jan Kratochvil
2010-05-16 21:49                                   ` Jonas Maebe
2010-05-16 21:55                                     ` Jonas Maebe
2010-05-16 18:31                               ` Jan Kratochvil

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=20100515214421.GA9965@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=archer@sourceware.org \
    --cc=joost@cnoc.nl \
    /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).