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

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.

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


  reply	other threads:[~2022-02-25 16:53 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 [this message]
2022-02-25 20:25           ` Kevin Buettner

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=DM8PR11MB5749745781769F52FAC5EEF7DE3E9@DM8PR11MB5749.namprd11.prod.outlook.com \
    --to=markus.t.metzger@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=kevinb@redhat.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).