Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Weimin Pan <weimin.pan@oracle.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string"
Date: Thu, 25 Jan 2018 04:14:00 -0000	[thread overview]
Message-ID: <20180125041431.tghhxefsgxnxh3l3@adacore.com> (raw)
In-Reply-To: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com>

> To support C99 VLA, function value_from_contents_and_address() was
> modified to add a call to resolve_dynamic_type(), which in turn
> calls resolve_dynamic_array() to resolve the dynamic array bounds
> to static values. But the problem arises when function copy_type(),
> called by resolve_dynamic_array(), expects the type to be copied
> to have an associated objfile from which the new type is allocated,
> or asserts. Since type char[] doesn't have an associated objfile
> when the following gdb command:
> 
> (gdb) set {char[]}$pc="hello"
> 
> was issued, gdb asserts.
> 
> The gdb_assert (TYPE_OBJFILE_OWNED (type)) line in copy_type() doesn't
> look necessary or correct since space needed for the new type could be
> allocated from either the type's objfile if it exists or gdbarch if
> it doesn't, similar to what alloc_type_copy(), which is called after
> gdb_assert() in copy_type(), does. Removing gdb_assert() fixes the
> problem.

I think removing the assert just shifts the issue elsewhere.
Basically, you want the lifetime of the new type to match
the lifetime of the object using it. The gdbarch structure
has a lifetime that's different from objfiles.

I happen to have hit the same issue as you, but from an Ada expression,
and sent it a fix not long ago:
https://www.sourceware.org/ml/gdb-patches/2018-01/msg00240.html

Does it fix your problem too?

-- 
Joel


  reply	other threads:[~2018-01-25  4:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25  2:12 Weimin Pan
2018-01-25  4:14 ` Joel Brobecker [this message]
2018-01-25 22:24   ` Wei-min Pan
2018-01-31  7:45     ` Joel Brobecker
2018-02-01  1:46       ` Wei-min Pan
2018-02-01  8:00         ` Joel Brobecker
2018-02-02  1:14           ` Wei-min Pan
2018-11-14 23:38           ` Wei-min Pan
2018-11-14 23:51             ` Joel Brobecker
2018-11-15  0:16               ` Wei-min Pan
2018-11-29 19:18                 ` Tom Tromey
2018-11-29 21:10                   ` Wei-min Pan
2018-11-29 21:52                     ` Tom Tromey
2018-11-29 23:26                       ` Wei-min Pan
2018-11-30 15:37                         ` Tom Tromey
2018-11-30 17:31                           ` Wei-min Pan

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=20180125041431.tghhxefsgxnxh3l3@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=weimin.pan@oracle.com \
    /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