public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@gmail.com>
To: Vivek Das Mohapatra <vivek@collabora.com>
Cc: Michael Matz <matz@suse.de>, gnu-gabi@sourceware.org
Subject: Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE
Date: Wed, 17 Jun 2020 11:23:46 -0700	[thread overview]
Message-ID: <CAJimCsE8E7x+yUg_Zuy84YT75XvLOua=M6wsnDOWeOgyRFbZrw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.2006171718010.2022@noise.cbg.collabora.co.uk>

> I should open by saying I originally implemented this as a new bitfield
> value for the payload of DT_FLAGS_1, but was told a new DT_GNU_… section
> might be more palatable/portable/less-conflict-prone.

I don't know why you were advised that, but it seems to me that using
DT_FLAGS_1 is the right approach. Dynamic table tags are meant to
convey a value other than a simple boolean; if all you need is a flag,
well, that's what DT_FLAGS and DT_FLAGS_1 are for. For precedent, note
that the old dynamic table entries DT_SYMBOLIC, DT_TEXTREL, and
DT_BIND_NOW have all been replaced by flags in DT_FLAGS.

DT_FLAGS_1 is a Gnu extension, so it's the place for a Gnu-specific
flag. Perhaps the concern was that DT_FLAGS_1 is also used by Solaris,
so I suppose you'd want to get agreement from them to use one of those
bits. You could always add a DT_GNU_FLAGS if DT_FLAGS_1 isn't
acceptable.

-cary

  reply	other threads:[~2020-06-17 18:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200617135945.12716-1-vivek@collabora.com>
     [not found] ` <CAMe9rOr7PVkz1k8dAPXoJjiCjiQ32f26ZduMX6xuxbGzguG=zQ@mail.gmail.com>
2020-06-17 16:00   ` Vivek Das Mohapatra
2020-06-17 16:16     ` Michael Matz
2020-06-17 16:37       ` Vivek Das Mohapatra
2020-06-17 18:23         ` Cary Coutant [this message]
2020-06-17 19:13           ` Vivek Das Mohapatra
2020-06-26 15:12             ` [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE Vivek Das Mohapatra
2020-06-26 15:29               ` H.J. Lu
     [not found]                 ` <ca72c789-f60c-2eaf-18e9-a7e59fcb0319@Oracle.COM>
     [not found]                   ` <CAMe9rOqF-zUUsCeyiT8s20bhTeVhozZtGkAD-JRrNiEOaju7jQ@mail.gmail.com>
     [not found]                     ` <8af0af5a-9fd4-2e80-1dff-ff714a15a6b2@Oracle.COM>
     [not found]                       ` <20200626173513.22arn2ihwgxudmjf@google.com>
     [not found]                         ` <CAMe9rOorOgV6wT3gHVdfK-zKp11kUVcqtBZHSSd__EdQtWvcKw@mail.gmail.com>
2020-06-26 18:34                           ` H.J. Lu

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='CAJimCsE8E7x+yUg_Zuy84YT75XvLOua=M6wsnDOWeOgyRFbZrw@mail.gmail.com' \
    --to=ccoutant@gmail.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=matz@suse.de \
    --cc=vivek@collabora.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).