[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Document existing GNU extensions



On Fri, Feb 19, 2016 at 02:26:15PM -0800, H.J. Lu wrote:
> There are many GNU extensions in GCC, binutils and glibc.  Some of
> them are
> 
> PT_GNU_EH_FRAME
> STT_GNU_IFUNC
> PT_GNU_STACK
> PT_GNU_RELRO
> SHT_GNU_INCREMENTAL_INPUTS
> SHT_GNU_ATTRIBUTES
> SHT_GNU_HASH
> SHT_GNU_LIBLIST
> SHT_GNU_verdef
> SHT_GNU_verneed
> SHT_GNU_versym
> STB_GNU_UNIQUE
> DT_GNU_PRELINKED
> DT_GNU_CONFLICTSZ
> DT_GNU_LIBLISTSZ
> DT_GNU_HASH
> DT_GNU_CONFLICT
> DT_GNU_LIBLIST
> DT_RELCOUNT
> DT_RELACOUNT
> .note.ABI-tag
> .note.GNU-stack

That is a nice list to start with, thanks.

> Most of their documentations are with the source codes or spread over
> multiple email messages in various mailing list archives.  There is no
> central place to look them up.

Right, that is why we set up this group.

> I documented 2 of them:
> 
> PT_GNU_EH_FRAME
> STT_GNU_IFUNC
> 
> and put them at
> 
> https://github.com/hjl-tools/linux-abi
> 
> Is there a git repo I can use on sourceware.org?

Not yet. But we should get one once we have concensus about how to
make sure we document things.

I hope we can do it with minimal rules, just discuss any proposals to
document things on this list till there is concensus on the wording.

I propose we invite the global maintainers of each of the GNU toolchain
projects (gcc, gdb, binutils and glibc) to appoint one reviewer/approver
who is responsible for making sure anything we document is actually a
stable GNU gabi extension they are willing to support (and not some
accidental mistake that might seem to work, but was never intented as
public abi). Their job would simply be to say "yes", "no" or "please,
refer to another standard or project documentation as official source"
about any text we come up with that has concensus. That way we make sure
that what we document is actually supported by the GNU toolchain projects
for others to rely on.

Cheers,

Mark