unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>
To: Florian Weimer <fw@deneb.enyo.de>,
	Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>
Cc: Pedro Alves <palves@redhat.com>,
	Conan C Huang <conhuang@cisco.com>,
	Jeremy Stenglein <jstengle@cisco.com>,
	xe-linux-external@cisco.com
Subject: Re: [RFC PATCH 3/3] add r_debug multiple namespaces support
Date: Sun, 28 Jun 2020 08:34:32 -0400	[thread overview]
Message-ID: <8a15bd93-e4cc-a3bc-f902-5b3e701ec4e3@redhat.com> (raw)
In-Reply-To: <87ftagyhra.fsf@mid.deneb.enyo.de>

On 6/27/20 5:34 AM, Florian Weimer wrote:
> * Carlos O'Donell via Libc-alpha:
> 
>> Truncated in which way?
> 
> This part:
> 
> | Your proposed solution of bumping the version is unacceptable,
> | and was last rejected by Roland McGrath. The problem is that
> | when you bump the version the current 

Thanks. "It's Friday" is my only excuse.

I did provide some of the original links to the discussion.

Roland, as a steward at the time, was worried about exactly what
we see in gdb, which is "r_version != 1" may have made it into tooling.

We can test this. We can try to deploy a similar solution in Fedora Rawhide
and declare the semantics as we expect them to be.

That is to say that r_version == 1, is the entire structure as we have it,
and r_version == 2 *adds* but does not remove from the structure. Since
the data is maintained by the implementation and the caller is only
inspecting the data it should work.

>> I'm not sure it would work to version _r_debug, since the debugger
>> is using DT_DEBUG and we only get to put one value in that
>> .dynamic entry.
> 
> The symbol version is needed to avoid problems due to copy relocations
> if the symbol is referenced directly from the main program.  Without
> that, the object could be truncated.  It's not a debugger
> compatibility feature.

Correct, but this violates *how* you're supposed to use _r_debug.

If you have a static executable you can get away with referencing
_r_debug directly, but in that case symbol versions don't matter, and
you have whatever version you have at the time.

In the dynamic case it is different. The symbol should be looked up
via DT_DEBUG only which always points to the library-local address
of the data object (and the most recent version). In effect this
bypasses the COPY relocation?

If an application uses _r_debug, the symbol, directly, then they
should get a static copy via the COPY relocation, and it will not
be updated after that. Perhaps we can arrange for such an initial
_r_debug to indicate it's not active or initialized?

IMO the library should use a local-only reference to the _r_debug to
avoid going through the global reference.

I'm not keen to admit that a COPY reloc of _r_debug should work.

-- 
Cheers,
Carlos.


  reply	other threads:[~2020-06-28 12:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26 19:32 [RFC PATCH 3/3] add r_debug multiple namespaces support Daniel Walker via Libc-alpha
2020-06-26 21:05 ` Florian Weimer via Libc-alpha
2020-06-26 21:19   ` Carlos O'Donell via Libc-alpha
2020-06-26 21:24     ` Florian Weimer via Libc-alpha
2020-06-26 21:44       ` Carlos O'Donell via Libc-alpha
2020-06-27  9:34         ` Florian Weimer
2020-06-28 12:34           ` Carlos O'Donell via Libc-alpha [this message]
2020-06-29  8:51             ` Florian Weimer via Libc-alpha
2021-07-23 23:38               ` H.J. Lu via Libc-alpha
2021-07-27 17:39                 ` Daniel Walker via Libc-alpha
2021-07-27 18:14                   ` H.J. Lu via Libc-alpha
2021-07-28 15:15                     ` H.J. Lu via Libc-alpha
2021-07-28 15:44                       ` Daniel Walker via Libc-alpha
2021-07-28 17:14                         ` H.J. Lu via Libc-alpha
2021-07-28 19:02                           ` Daniel Walker via Libc-alpha
2021-07-28 20:04                             ` H.J. Lu via Libc-alpha
2021-08-02  4:24                               ` RFC: Add DT_GNU_DEBUG H.J. Lu via Libc-alpha
2021-08-02  5:22                                 ` Florian Weimer via Libc-alpha
2021-08-02 13:10                                   ` H.J. Lu via Libc-alpha
2021-08-03 16:39                                     ` Daniel Walker via Libc-alpha
2021-08-03 18:08                                       ` H.J. Lu via Libc-alpha
2021-08-03 20:04                                         ` Daniel Walker via Libc-alpha
2021-08-03 18:12                                       ` Florian Weimer via Libc-alpha
2021-08-03 18:23                                         ` H.J. Lu via Libc-alpha
2021-08-03 20:13                                           ` Florian Weimer via Libc-alpha
2021-08-03 20:21                                             ` H.J. Lu via Libc-alpha
2021-08-09 14:32                                               ` RFC: 2 choices of DT_XXX for dlmopen H.J. Lu via Libc-alpha
2021-08-09 17:16                                                 ` Daniel Walker via Libc-alpha
2021-08-15  0:33                                                   ` [PATCH] Extend struct r_debug to support multiple namespaces H.J. Lu via Libc-alpha
2021-08-16 16:20                                                     ` Daniel Walker via Libc-alpha
2021-08-17  1:07                                                       ` H.J. Lu via Libc-alpha
2020-06-27  1:21       ` [RFC PATCH 3/3] add r_debug multiple namespaces support Daniel Walker (danielwa) via Libc-alpha

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

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a15bd93-e4cc-a3bc-f902-5b3e701ec4e3@redhat.com \
    --to=libc-alpha@sourceware.org \
    --cc=carlos@redhat.com \
    --cc=conhuang@cisco.com \
    --cc=fw@deneb.enyo.de \
    --cc=jstengle@cisco.com \
    --cc=palves@redhat.com \
    --cc=xe-linux-external@cisco.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).