Re: Linux-abi group

[Suprateeka R Hegde via cfe-commits]

H.J,

I think we are fragmenting with too many standards and mailing lists. 
This new discussion group and eventually the resulting standards, all 
might be put under LSB http://refspecs.linuxfoundation.org/lsb.shtml


The Intro on LSB says: 
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html


And thats what this proposal is intended for.

And we can use the LSB mailing list 
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all 
discussions.


What do you think?

--
Supra


On 09-Feb-2016 08:46 AM, H.J. Lu via llvm-commits wrote:

On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers  wrote:

On Mon, 8 Feb 2016, H.J. Lu wrote:


I was referring to program properties:

https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8


This looks more like an ELF topic to me, not really ABI.

Please discuss this on a GNU project list because it affects the
entire GNU project.



gABI is ELF and affects all users, including GNU project, of gABI.
Linux-abi discusses Linux-specific extensions to gABI. It is for tools
like compilers, assembler, linker and run-time.  It isn't appropriate
for any GNU project list.


I find it extremely unlikely that many well-thought-out extensions would
be appropriate for GNU systems using the Linux kernel but not for GNU
systems using Hurd or other kernels - the only such cases would be for
things very closely related to kernel functionality.  There is a strong
presumption that toolchain configuration should apply to all GNU systems
rather than being specific to GNU/Linux without good reason.



Most of extensions aren't Linux kernel specific.  But some extensions
will require kernel support to function properly.



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
 wrote:
> H.J,
>
> I think we are fragmenting with too many standards and mailing lists. This
> new discussion group and eventually the resulting standards, all might be
> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>
> The Intro on LSB says:
> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
>
> And thats what this proposal is intended for.
>
> And we can use the LSB mailing list
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
> discussions.
>
> What do you think?
>

LSB lists extensions which have been implemented.  But it isn't a spec
you can use to implement them.  For example:

http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html

lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details.  Linux ABI group is the place where we propose
extensions before they get implemented.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Ed Maste via cfe-commits]

On 8 February 2016 at 18:08, Joseph Myers  wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks more like an ELF topic to me, not really ABI.
>> >
>> > Please discuss this on a GNU project list because it affects the
>> > entire GNU project.
>> >
>>
>> gABI is ELF and affects all users, including GNU project, of gABI.
>> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
>> like compilers, assembler, linker and run-time.  It isn't appropriate
>> for any GNU project list.

But the examples presented so far (STT_GNU_IFUNC, PT_GNU_RELRO etc.)
are relevant to GNU systems in general and are not Linux-specific.

> I find it extremely unlikely that many well-thought-out extensions would
> be appropriate for GNU systems using the Linux kernel but not for GNU
> systems using Hurd or other kernels - the only such cases would be for
> things very closely related to kernel functionality.  There is a strong
> presumption that toolchain configuration should apply to all GNU systems
> rather than being specific to GNU/Linux without good reason.

Agreed. As we've seen with the fallout from the abi_tag attribute we
need better communication between groups in the free software tool
chain world, not more fragmentation.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Suprateeka R Hegde via cfe-commits]

On 11-Feb-2016 07:21 PM, H.J. Lu wrote:

On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
 wrote:

H.J,

I think we are fragmenting with too many standards and mailing lists. This
new discussion group and eventually the resulting standards, all might be
put under LSB http://refspecs.linuxfoundation.org/lsb.shtml

The Intro on LSB says:
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html

And thats what this proposal is intended for.

And we can use the LSB mailing list
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
discussions.

What do you think?



LSB lists extensions which have been implemented.  But it isn't a spec
you can use to implement them.  For example:

http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html

lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details.  Linux ABI group is the place where we propose
extensions before they get implemented.


How to implement, according to me, is design details of a particular 
product. It also depends on the language used to develop the product. 
Standards, in most cases, are not tied to a language and hence do not 
enforce implementation details.


For instance, the document "ELF Handling of Thread Local Storage" is a 
technical whitepaper that encourages a way of implementation. It is not 
an official extension.


I meant, use LSB mailing lists for proposals and after implementation, 
update the LSB for all future references. If there is a need to show 
implementation details, it should be a separate document.


My suggestion is to create something for all (entire Linux and not just 
ABI) and make the ABI part of it. So as per your description of LSB, we 
need a namespace something like LSB-Draft where entire Linux community 
can discuss proposals and ABI is part of it.


Also, another namespace within LSB that holds documents showing example 
implementations.


As we see through this discussion, there are many mailing lists and 
groups with lot of overlaps. I think we have to prevent more such 
fragmentation.


These are the thoughts I had. Bottom line is that, a standard is always 
welcome. It is beneficial to all across industry.


--
Supra
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde
 wrote:
> On 11-Feb-2016 07:21 PM, H.J. Lu wrote:
>>
>> On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
>>  wrote:
>>>
>>> H.J,
>>>
>>> I think we are fragmenting with too many standards and mailing lists.
>>> This
>>> new discussion group and eventually the resulting standards, all might be
>>> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>>>
>>> The Intro on LSB says:
>>>
>>> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
>>>
>>> And thats what this proposal is intended for.
>>>
>>> And we can use the LSB mailing list
>>> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
>>> discussions.
>>>
>>> What do you think?
>>>
>>
>> LSB lists extensions which have been implemented.  But it isn't a spec
>> you can use to implement them.  For example:
>>
>>
>> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html
>>
>> lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
>> But it gives no details.  Linux ABI group is the place where we propose
>> extensions before they get implemented.
>
>
> How to implement, according to me, is design details of a particular
> product. It also depends on the language used to develop the product.
> Standards, in most cases, are not tied to a language and hence do not
> enforce implementation details.
>
>

That is exactly what Linux ABI group tries to address.  Please see
the Linux gABI extension draft at

https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI

It describes the conventions and constraints on the implementa-
tion of these extensions for interoperability between various tools.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Joerg Sonnenberger via cfe-commits]

On Thu, Feb 11, 2016 at 10:50:29AM -0500, Ed Maste via llvm-commits wrote:
> On 8 February 2016 at 18:08, Joseph Myers  wrote:
> > On Mon, 8 Feb 2016, H.J. Lu wrote:
> >
> >> >> I was referring to program properties:
> >> >>
> >> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
> >> >
> >> > This looks more like an ELF topic to me, not really ABI.
> >> >
> >> > Please discuss this on a GNU project list because it affects the
> >> > entire GNU project.
> >> >
> >>
> >> gABI is ELF and affects all users, including GNU project, of gABI.
> >> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
> >> like compilers, assembler, linker and run-time.  It isn't appropriate
> >> for any GNU project list.
> 
> But the examples presented so far (STT_GNU_IFUNC, PT_GNU_RELRO etc.)
> are relevant to GNU systems in general and are not Linux-specific.

Some of them are even useful outside GNU systems. Some others choices in
recent years are at least somewhat questionable and a broader audience
in the design would likely have made the design much more useful (i.e.
the GNU hash format).

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Joseph Myers via cfe-commits]

On Thu, 11 Feb 2016, Suprateeka R Hegde wrote:

> H.J,
> 
> I think we are fragmenting with too many standards and mailing lists. This new
> discussion group and eventually the resulting standards, all might be put
> under LSB http://refspecs.linuxfoundation.org/lsb.shtml
> 
> The Intro on LSB says:
> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
> 
> And thats what this proposal is intended for.
> 
> And we can use the LSB mailing list
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
> discussions.
> 
> What do you think?

I think that none of the ABI extensions in question are anything to do 
with Linux, the kernel.  Rather, they are ABI extensions for userspace in 
the GNU system, which apply the same under multiple kernels (but some of 
them may well not apply to Android systems using the Linux kernel, for 
example, if the Bionic C library and dynamic linker lack the relevant 
features).  Thus it would be more appropriate for a mailing list to be 
hosted on sourceware or Savannah, and for any resulting documents to refer 
to GNU, not to Linux.

-- 
Joseph S. Myers
jos...@codesourcery.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers  wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks more like an ELF topic to me, not really ABI.
>> >
>> > Please discuss this on a GNU project list because it affects the
>> > entire GNU project.
>> >
>>
>> gABI is ELF and affects all users, including GNU project, of gABI.
>> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
>> like compilers, assembler, linker and run-time.  It isn't appropriate
>> for any GNU project list.
>
> I find it extremely unlikely that many well-thought-out extensions would
> be appropriate for GNU systems using the Linux kernel but not for GNU
> systems using Hurd or other kernels - the only such cases would be for
> things very closely related to kernel functionality.  There is a strong
> presumption that toolchain configuration should apply to all GNU systems
> rather than being specific to GNU/Linux without good reason.
>

Most of extensions aren't Linux kernel specific.  But some extensions
will require kernel support to function properly.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Szabolcs Nagy via cfe-commits]

* H.J. Lu  [2016-02-08 11:24:53 -0800]:
> I created a mailing list to discuss Linux specific,.processor independent
> modification and extension of generic System V Application Binary Interface:
> 
> https://groups.google.com/d/forum/linux-abi
> 
> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
> I will propose some new extensions soon.
> 

seems to require a registered email address at google.
(and the archive does not work from any console based browser
or using direct http get tools.)

the kernel seems to have a lot of mailing lists, may be
they can handle this list too?

thanks
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Florian Weimer via cfe-commits]

* H. J. Lu:

> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer  wrote:
>> * H. J. Lu:
>>
>>> I created a mailing list to discuss Linux specific,.processor independent
>>> modification and extension of generic System V Application Binary Interface:
>>>
>>> https://groups.google.com/d/forum/linux-abi
>>>
>>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>>> I will propose some new extensions soon.
>>
>> Why can't you use the existing C++ ABI list?  Is there no overlap at
>> all?
>>
> :
> I wasn't referring to empty class
>
> https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html

But still there is going to be some overlap?

> I was referring to program properties:
>
> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8

This looks more like an ELF topic to me, not really ABI.

Please discuss this on a GNU project list because it affects the
entire GNU project.

Florian
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer  wrote:
> * H. J. Lu:
>
>> I created a mailing list to discuss Linux specific,.processor independent
>> modification and extension of generic System V Application Binary Interface:
>>
>> https://groups.google.com/d/forum/linux-abi
>>
>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>> I will propose some new extensions soon.
>
> Why can't you use the existing C++ ABI list?  Is there no overlap at
> all?
>
:
I wasn't referring to empty class

https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html

I was referring to program properties:

https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 11:33 AM, Szabolcs Nagy  wrote:
> * H.J. Lu  [2016-02-08 11:24:53 -0800]:
>> I created a mailing list to discuss Linux specific,.processor independent
>> modification and extension of generic System V Application Binary Interface:
>>
>> https://groups.google.com/d/forum/linux-abi
>>
>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>> I will propose some new extensions soon.
>>
>
> seems to require a registered email address at google.
> (and the archive does not work from any console based browser
> or using direct http get tools.)

Do you want me to add you?

> the kernel seems to have a lot of mailing lists, may be
> they can handle this list too?
>
> thanks

It is used to discuss more tool-oriented extensions than
the kernel-oriented ones, like STT_GNU_IFUNC which
has nothing to do with kernel.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 11:44 AM, Florian Weimer  wrote:
> * H. J. Lu:
>
>> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer  wrote:
>>> * H. J. Lu:
>>>
 I created a mailing list to discuss Linux specific,.processor independent
 modification and extension of generic System V Application Binary 
 Interface:

 https://groups.google.com/d/forum/linux-abi

 I will start to document existing Linux extensions, like STT_GNU_IFUNC.
 I will propose some new extensions soon.
>>>
>>> Why can't you use the existing C++ ABI list?  Is there no overlap at
>>> all?
>>>
>> :
>> I wasn't referring to empty class
>>
>> https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html
>
> But still there is going to be some overlap?

I was told that it didn't belong to C++ ABI.  Please free feel to
raise the this issue with C++ ABI group.

>> I was referring to program properties:
>>
>> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>
> This looks more like an ELF topic to me, not really ABI.
>
> Please discuss this on a GNU project list because it affects the
> entire GNU project.
>

gABI is ELF and affects all users, including GNU project, of gABI.
Linux-abi discusses Linux-specific extensions to gABI. It is for tools
like compilers, assembler, linker and run-time.  It isn't appropriate
for any GNU project list.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Joseph Myers via cfe-commits]

On Mon, 8 Feb 2016, H.J. Lu wrote:

> >> I was referring to program properties:
> >>
> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
> >
> > This looks more like an ELF topic to me, not really ABI.
> >
> > Please discuss this on a GNU project list because it affects the
> > entire GNU project.
> >
> 
> gABI is ELF and affects all users, including GNU project, of gABI.
> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
> like compilers, assembler, linker and run-time.  It isn't appropriate
> for any GNU project list.

I find it extremely unlikely that many well-thought-out extensions would 
be appropriate for GNU systems using the Linux kernel but not for GNU 
systems using Hurd or other kernels - the only such cases would be for 
things very closely related to kernel functionality.  There is a strong 
presumption that toolchain configuration should apply to all GNU systems 
rather than being specific to GNU/Linux without good reason.

-- 
Joseph S. Myers
jos...@codesourcery.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits