public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: gdb-patches@sourceware.org, "H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: [PATCH v3] Support glibc multiple namespace extension
Date: Fri, 25 Feb 2022 13:25:55 -0700	[thread overview]
Message-ID: <20220225132555.122bd92c@f35-zws-1> (raw)
In-Reply-To: <DM8PR11MB5749745781769F52FAC5EEF7DE3E9@DM8PR11MB5749.namprd11.prod.outlook.com>

On Fri, 25 Feb 2022 16:53:38 +0000
"Metzger, Markus T" <markus.t.metzger@intel.com> wrote:

> Hello Kevin,
> 
> >This is indeed wrong and leads to
> >
> >      if (li->l_prev != prev_lm)
> >	{
> >	  warning (_("Corrupted shared library list: %s != %s"),
> >		   paddress (target_gdbarch (), prev_lm),
> >		   paddress (target_gdbarch (), li->l_prev));
> >	  return 0;
> >	}
> >
> >in svr4_read_so_list().  Assigning prev_lm to zero avoided the warning for
> >the first library in another namespace.  I added more test cases to detect
> >this reliably.
> >
> >I'll try organizing SVr4 DSOs in per-namespace lists.  
> 
> That works.  During testing I noticed
> 
> 	Invalid cast.
> 	warning: Probes-based dynamic linker interface failed.
> 	Reverting to original interface.
> 
> on dlcose().  This can also be reproduced with gdb.base/unload.exp
> and upstream GDB.  I have not looked into this, yet.
> 
> This is not detected by the test system and I'm not sure whether we
> actually want to consider falling back to the old interface a test fail.
> The invalid cast error we probably want to detect.
> 
> I added support for detecting this invalid cast and the corrupted
> library list warning in gdb_continue_to_breakpoint.
> 
> I still need to extend the library-list-svr4 XML to cover namespaces
> before I send an updated patch.  I'll be out the next week so this
> will take a while.
> 
> I currently check the XML version and put everything into a special
> namespace on the GDB side.  We cannot use incremental updates
> this way but we're backwards compatible.  The final version will
> support both the new format with namespaces and incremental
> updates and the old format without.

This sounds like good progress!

I look forward to seeing your next patch...

Kevin


      reply	other threads:[~2022-02-25 20:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-02  0:11 [PATCH v2] " H.J. Lu
2021-10-02 20:43 ` [PATCH v3] " H.J. Lu
2022-02-10 23:08   ` Kevin Buettner
2022-02-16  0:43     ` H.J. Lu
2022-02-16 11:10     ` Metzger, Markus T
2022-02-21  6:53       ` Metzger, Markus T
2022-02-25 16:53         ` Metzger, Markus T
2022-02-25 20:25           ` Kevin Buettner [this message]

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=20220225132555.122bd92c@f35-zws-1 \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=markus.t.metzger@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).