This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH, MIPS] Support shared library debug with MIPS PIE
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 23 Jun 2015 19:22:14 +0100 (BST)
- Subject: RE: [PATCH, MIPS] Support shared library debug with MIPS PIE
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235321175C6A at LEMAIL01 dot le dot imgtec dot org> <alpine dot LFD dot 2 dot 11 dot 1506231640020 dot 31814 at eddie dot linux-mips dot org> <6D39441BF12EF246A7ABCE6654B02353211766DA at LEMAIL01 dot le dot imgtec dot org>
On Tue, 23 Jun 2015, Matthew Fortune wrote:
> > We've been using GNU extensions (e.g. GNU ELF attributes) for other
> > purposes with no concern whatsoever about other OSes. And they are free
> > to adopt them. So what is your specific concern about DT_GNU_RLD_MAP?
> The whole .gnu_attribute feature can be adopted easily by other OSs as it is
> unlikely that they have also defined some section called .gnu_attribute for
> other purposes. This is different from the dedicated ranges of dynamic tags
> for gABI, psABI and OS. There is very little guarantee that the OS tag range
> will not overlap between OSs and nor should there be such a guarantee as that
> is the purpose of separate ranges.
> > With that in mind and given that this is a generic feature to support PIE
> > while keeping the dynamic segment r/o, do you maintain it would better go
> > with the ELF gABI rather than as a GNU extension? I suspect with a good
> > justification, that I believe we have here, reserving a dynamic tag number
> > with the gABI maintainers shouldn't take a lot of time or effort.
> Yes. I'm opposed to using the OS range of dynamic tags. I'd also like to
> see genuine interest and commitment from other architecture maintainers
> to add the option of a read-only dynamic segment before looking at a gABI
> change though. I think this could just end up as one of the many features
> that 'could' be used, but is not.
Fair enough. I have no further input to add as to the choice of the tag
range to put the new tag in, so unless another architecture maintainer
speaks out I'll have no objection to your change.
May I ask for a more meaningful name for the tag though, like
DT_MIPS_RLD_MAP_REL (for RELative)?