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
next prev parent 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).