Re: Linux-abi group
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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 22:40, H.J. Lu wrote:
> "empty type". An empty type is either an array of empty types or a
> class type where every member is of empty type.
Note that the term "empty type" is commonly used in type theory to
denote a (or the) type with no values. The closest thing C has would be
an empty enum when using -fstrict-enums. (Declaring it as return type
implies [[noreturn]] or undefined behaviour.)
A type with a unique value (such as void or an empty struct) is usually
known as a unit type.
BTW, being standard layout is not sufficient (nor required afaict) for
zero-register passing of a unit type. The requirement you need is
trivially-copyable. Example:
#include
#include
#include
using namespace std;
class EmptyInt {
static map< const EmptyInt *, int > values;
public:
EmptyInt() = default;
EmptyInt( int x ) { values[this] = x; }
~EmptyInt() { values.erase(this); }
operator int () const { return values[this]; }
};
typeof( EmptyInt::values ) EmptyInt::values;
EmptyInt foo() {
return 42;
}
int main() {
cout << is_standard_layout{} << endl;
cout << foo() << endl;
return 0;
}
This evil contraption satisfies all POD-requirements except for not
being trivially-copyable. On the other hand taking this example from
http://en.cppreference.com/w/cpp/concept/StandardLayoutType
struct Q {};
struct S : Q {};
struct T : Q {};
struct U : S, T {}; // not a standard-layout class
Even though U is not standard-layout, it is trivially-copyable and I see
no reason to allocate a register to pass it.
Matthijs van Duin
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 2:47 AM, Matthijs van Duin
wrote:
> On 8 February 2016 at 22:40, H.J. Lu wrote:
>> "empty type". An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>
> Note that the term "empty type" is commonly used in type theory to
> denote a (or the) type with no values. The closest thing C has would be
> an empty enum when using -fstrict-enums. (Declaring it as return type
> implies [[noreturn]] or undefined behaviour.)
>
> A type with a unique value (such as void or an empty struct) is usually
> known as a unit type.
>
> BTW, being standard layout is not sufficient (nor required afaict) for
> zero-register passing of a unit type. The requirement you need is
> trivially-copyable. Example:
>
> #include
> #include
> #include
>
> using namespace std;
>
> class EmptyInt {
> static map< const EmptyInt *, int > values;
>
> public:
> EmptyInt() = default;
> EmptyInt( int x ) { values[this] = x; }
> ~EmptyInt() { values.erase(this); }
>
> operator int () const { return values[this]; }
> };
>
> typeof( EmptyInt::values ) EmptyInt::values;
>
> EmptyInt foo() {
> return 42;
> }
>
> int main() {
> cout << is_standard_layout{} << endl;
> cout << foo() << endl;
> return 0;
> }
My current proposal is
1. "class type". A class type is a structure, union or C++ class.
2. "empty type". An empty type is Plain Old Data (POD) for the
purposes of layout, and.a type where it and all of its subobjects
are of class or array type.
> This evil contraption satisfies all POD-requirements except for not
> being trivially-copyable. On the other hand taking this example from
> http://en.cppreference.com/w/cpp/concept/StandardLayoutType
>
> struct Q {};
> struct S : Q {};
> struct T : Q {};
> struct U : S, T {}; // not a standard-layout class
>
> Even though U is not standard-layout, it is trivially-copyable and I see
> no reason to allocate a register to pass it.
>
Since this isn't Plain Old Data (POD) for the purposes of layout, it
isn't covered by my proposal for psABI. I leave this to C++ ABI.
--
H.J.
RE: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register
Sorry for the slow response... Andreas Arnez writes: > On Mon, Jan 25 2016, Matthew Fortune wrote: > > > My dwarf knowledge is not brilliant but I have had to recently > > consider it for MIPS floating point ABI changes aka FPXX and friends. > > I don't know exactly where this fits in to your whole description but > > in case it has a bearing on this we now have the following uses of > DW_OP_piece: > > > > 1) double precision data split over two 32-bit FPRs > > Uses a pair of 32-bit DW_OP_piece (ordered depending on endianness). > > > > 2) double precision data in one 64-bit FPR > > No need for DW_OP_piece. > > > > 3) double precision data that may be in two 32-bit FPRs or may be in > >one 64-bit FPR depending on hardware mode > > Uses a single 64-bit DW_OP_piece on the even numbered register. > > Hm, so in 32-bit hardware mode the DWARF consumer is expected to treat > the DW_OP_piece on the even numbered register as if it were two pieces > from two consecutive registers? Yes. > Or should we rather consider the even > numbered register to be 64 bit wide, where the right half shadows the > next odd-numbered register? If so, I believe you generally want pieces > from FPRs to be taken from the left, correct? No I think this is backwards it is the left half that shadows the next register and pieces are taken from the right. I've attempted a description below to see if it helps. I don't believe (in the MIPS case) we could unconditionally view the even numbered register as 64-bit or 32-bit as the shadowing onto the next register only exists in some hardware modes. The size of a register has to be determined from the current hardware mode and then the logic would be to read as much as possible from the referenced register and use it as the lower bits of the overall value. Then continue reading consecutive registers filling the next most significant bits until the full size of the DW_OP_piece has been read. This for MIPS FP registers is endian agnostic as the higher numbered register always has the most significant bits. For GPRs the even numbered register will provide either the most or least significant bits depending on endian but we have no reason to use this paradoxical DW_OP_piece for GPRs as they have compile time deterministic size. > > I'm guilty of not actually finishing this off and doing the GDB side > > but the theory seemed OK when I did it! From your description this > > behaviour best matches DW_OP_piece having ABI dependent behaviour > > which would make it acceptable. These three variations can potentially > > exist in the same program albeit that (1) and (3) can't appear in a > > single shared library or executable. It's all a little strange but the > > whole floating point MIPS o32 ABI is pretty complex now. > > I don't quite understand why (1) and (3) can not coexist in the same > shared library or executable. Can you elaborate a bit? Oops. Sorry it is (1) and (2) that can't coexist. I'm not sure you really want to know the gory details but the explanation is below if you're feeling brave. The reason these can't co-exist is really just because there would need to be yet another ABI variant/ELF marker to record the requirements of such an executable. It would be a combination of FP64A and FP32 and that would mandate a hardware mode of FR=1 FRE=1 which is the one mode that we desperately do not want to be in as it uses kernel emulation to make it all work. The combination of FP64A and FP32 ABIs is supported to enable some level of transition from original o32 (FP32) through to FP64 without requiring moving everything to FPXX first. We allow this across a shared library boundary to give just enough support for software to transition. The aim is to encourage the full transition to FPXX rather than going through a period of creating binaries that will always need kernel emulation regardless of the host architecture. > I'm curious about the interaction with vector registers. AFAIK, vector > registers on MIPS also embed the FPRs (left or right?). Probably best to compare NEON with other SIMD. MSA works like NEON on AArch64 rather than AArch32. I.e. it widens each register to 128-bit and uses the same DWARF registers as FPRs. A DW_OP_piece therefore corresponds to part of the 128-bit register. > Are the same DWARF register numbers used for both? Yes. I think we can get away with using the same dwarf numbers as the FPRs sit in the LSB of the vector register regardless of endian or double/single data but that is a moot point, see below. > And when taking a 64-bit DW_OP_piece from a vector register, would > this piece correspond to the embedded FPR? Strict architecture definition says no as the register sets do not necessarily have to be the same. In reality all the implementations I know of do simply have the FPU and SIMD unit use the same physical register set. However we would/should never consider a DW_OP_piece on a vector register to refer to the underlying FPR as there a
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 11 February 2016 at 11:53, H.J. Lu wrote: > Since this isn't Plain Old Data (POD) for the purposes of layout, it > isn't covered by my proposal for psABI. I leave this to C++ ABI. You never define "POD for the purposes of layout", and I can only interpret it as being equivalent to "standard-layout". The property of being trivially copyable/destructible is not a statement about layout and my EmptyInt example is POD in every other aspect. There's a good argument for trivially copyable/destructible being the relevant property: it means an object can be copied simply by copying its bytes and destroyed simply by discarding its storage. If the object occupies no storage (other than padding) then these operations become nops hence there is never a need to have a pointer/reference to the original object. The precise layout is not really important here, e.g. struct U is unusually large considering its lack of data members, due to the need for padding between its base classes, but this doesn't change the fact it can be copied using no operation (and g++ indeed does). Matthijs van Duin
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 11 February 2016 at 12:40, Matthijs van Duin wrote: > You never define "POD for the purposes of layout", and I can only > interpret it as being equivalent to "standard-layout". As Richard pointed out, it's defined in the C++ ABI.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 4:40 AM, Matthijs van Duin wrote: > On 11 February 2016 at 11:53, H.J. Lu wrote: >> Since this isn't Plain Old Data (POD) for the purposes of layout, it >> isn't covered by my proposal for psABI. I leave this to C++ ABI. > > You never define "POD for the purposes of layout", and I can only > interpret it as being equivalent to "standard-layout". The property of > being trivially copyable/destructible is not a statement about layout > and my EmptyInt example is POD in every other aspect. "POD for the purpose of layout" is defined in the Itanium C++ ABI here: http://mentorembedded.github.io/cxx-abi/abi.html#definitions -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 11 February 2016 at 13:58, H.J. Lu wrote: > "POD for the purpose of layout" is defined in the Itanium C++ ABI here: > > http://mentorembedded.github.io/cxx-abi/abi.html#definitions Sorry, I overlooked that. I still stand by my viewpoint however that triviality of copying and destruction is the appropriate criterion here rather than this obscure constraint on layout. Matthijs van Duin
Re: Linux-abi group
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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 5:44 AM, Matthijs van Duin wrote: > On 11 February 2016 at 13:58, H.J. Lu wrote: >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions > > Sorry, I overlooked that. > > I still stand by my viewpoint however that triviality of copying and > destruction is the appropriate criterion here rather than this obscure > constraint on layout. My focus is interoperability between C and C++: https://llvm.org/bugs/show_bug.cgi?id=26337 I intentionally exclude C++ specific features in my propose. However you have a very valid point. I encourage you to raise it with C++ ABI group: http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 11 February 2016 at 15:00, H.J. Lu wrote: > I intentionally exclude C++ specific features in my propose. Yet you use a definition from the Itanium C++ ABI which itself depends on multiple definitions in a particular version of the C++ standard, which depend on C++ specific features. This makes no sense to me. Note that triviality of copying/destruction holds for all C types and is easy to formulate in languages other than C++. (As is the notion of an aggregate requiring no storage, other than padding. The whole argument about array parameters seems a bit silly since this is mere syntax sugar, C/C++ do not support passing an actual array by value.) Matthijs van Duin
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 6:18 AM, Matthijs van Duin wrote: > On 11 February 2016 at 15:00, H.J. Lu wrote: >> I intentionally exclude C++ specific features in my propose. > > Yet you use a definition from the Itanium C++ ABI which itself depends > on multiple definitions in a particular version of the C++ standard, > which depend on C++ specific features. Yes, I used this C++ ABI definition to make C++ and C equivalent in empty type definition. > This makes no sense to me. > > Note that triviality of copying/destruction holds for all C types and > is easy to formulate in languages other than C++. (As is the notion of Can you point out which C++ features for empty type with C counter parts aren't covered by "POD for the purpose of layout"? > an aggregate requiring no storage, other than padding. The whole > argument about array parameters seems a bit silly since this is mere > syntax sugar, C/C++ do not support passing an actual array by value.) > > Matthijs van Duin -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Hi, On Thu, 11 Feb 2016, Jonathan Wakely wrote: > On 11 February 2016 at 12:40, Matthijs van Duin wrote: > > You never define "POD for the purposes of layout", and I can only > > interpret it as being equivalent to "standard-layout". > > As Richard pointed out, it's defined in the C++ ABI. Which is C++y as well (and hence doesn't in itself solve the C/C++ compatibility we should strive for in the ABI). I'll concur with Matthijs and think that trivially copyable is the correct distinction for passing without registers (in addition of it being clearer than a strangly defined concept of "POD-but-not-quite-POD"). Do you think different? Are there non-trivially copyable examples that we'd wish to pass without registers as well? Ciao, Michael.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 6:30 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, Jonathan Wakely wrote:
>
>> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
>> > You never define "POD for the purposes of layout", and I can only
>> > interpret it as being equivalent to "standard-layout".
>>
>> As Richard pointed out, it's defined in the C++ ABI.
>
> Which is C++y as well (and hence doesn't in itself solve the C/C++
> compatibility we should strive for in the ABI). I'll concur with Matthijs
> and think that trivially copyable is the correct distinction for passing
> without registers (in addition of it being clearer than a strangly defined
> concept of "POD-but-not-quite-POD"). Do you think different? Are there
> non-trivially copyable examples that we'd wish to pass without registers
> as well?
>
>
Any suggestions on new wording, something like
1. "class type". A class type is a structure, union or C++ class.
2. "empty type". An empty type is a type where it and all of its
subobjects are of class or array type.
Does it cover
struct A { };
struct B { };
struct C : A, B { };
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Hi,
On Thu, 11 Feb 2016, H.J. Lu wrote:
> Any suggestions on new wording, something like
>
> 1. "class type". A class type is a structure, union or C++ class.
> 2. "empty type". An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Does it cover
>
> struct A { };
> struct B { };
> struct C : A, B { };
I think this is covered by the above points. But without further
restriction I don't see how e.g. the above example with ctors and dtors
would be ruled out (except if you regard a ctor as a sub-object). For
that you seem to need trivially-copyable, or that POD-ly thing. So,
perhaps simply amend (2) "... is a trivially copyable type where it ...".
Ciao,
Michael.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
To avoid depending again on precise wording of definitions in C++
standard it may be worth being explicit about the requirement to be
trivially copyable *and* destructible, since although the former
implies the latter in the C++ standard this is not obvious from the
terminology (although you also need the latter in all practical cases
including the one being discussed).
The explanation I gave earlier ("it means an object can be copied
simply by copying its bytes and destroyed simply by discarding its
storage") can probably be polished into a language-agnostic
definition.
I think it is helpful in general when ABI standards can be extended to
other languages with as much ease and unambiguity as possible, for the
sake of interoperability.
For similar reasons I would support "aggregate occupying zero bytes
(excluding any padding)" with a footnote on the strange situation of
C/C++ arrays, which cannot be directly passed by value even if the
syntax may suggest they can (hence the rule being discussed is not
applicable to them).
Matthijs van Duin
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 11, 2016 at 6:54 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, H.J. Lu wrote:
>
>> Any suggestions on new wording, something like
>>
>> 1. "class type". A class type is a structure, union or C++ class.
>> 2. "empty type". An empty type is a type where it and all of its
>> subobjects are of class or array type.
>>
>> Does it cover
>>
>> struct A { };
>> struct B { };
>> struct C : A, B { };
>
> I think this is covered by the above points. But without further
> restriction I don't see how e.g. the above example with ctors and dtors
> would be ruled out (except if you regard a ctor as a sub-object). For
> that you seem to need trivially-copyable, or that POD-ly thing. So,
> perhaps simply amend (2) "... is a trivially copyable type where it ...".
>
>
> Ciao,
> Michael.
How about
struct A {
static void foo (void) ();
static int xxx;
};
--
H.J.
Re: Linux-abi group
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.
Re: Linux-abi group
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
Re: Linux-abi group
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.
Re: Linux-abi group
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
Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register
On Thu, Feb 11 2016, Matthew Fortune wrote: > No I think this is backwards it is the left half that shadows the next > register and pieces are taken from the right. I've attempted a description > below to see if it helps. > > I don't believe (in the MIPS case) we could unconditionally view the even > numbered register as 64-bit or 32-bit as the shadowing onto the next > register only exists in some hardware modes. > > The size of a register has to be determined from the current hardware mode > and then the logic would be to read as much as possible from the referenced > register and use it as the lower bits of the overall value. Then continue > reading consecutive registers filling the next most significant bits > until the full size of the DW_OP_piece has been read. This for MIPS > FP registers is endian agnostic as the higher numbered register always > has the most significant bits. For GPRs the even numbered register will > provide either the most or least significant bits depending on endian but > we have no reason to use this paradoxical DW_OP_piece for GPRs as they > have compile time deterministic size. Hm, so in the shadowed case, assuming that the DWARF consumer has loaded the register file into a byte array via ptrace, which bytes would the DW_OP_bit_piece offsets for FPR n correspond to? Is it like this for little-endian? FPR nFPR n+1 +---+---+---+---+ +---+---+---+---+ | | | | | | | | | | +---+---+---+---+ +---+---+---+---+ 0 8 16 2432 40 48 56 (In which case pieces would be taken from the left.) Or different? And for big-endian? -- Andreas
Helper for replaceAllUses in gcc gimple
Hello, Is there any implementation for replacing all uses of a variable with another variable in gimple? If I want to replace the uses of a variable with another one, do I have to do this by hand, investigate the type of the instruction and perform a replacement where necessary or is there any sort of helper available? In llvm, this can be done with Value::replaceAllUsesWith(Value *V). Thanks, Cristina
Re: Helper for replaceAllUses in gcc gimple
On February 11, 2016 6:39:02 PM GMT+01:00, Cristina Georgiana Opriceana wrote: >Hello, > >Is there any implementation for replacing all uses of a variable with >another variable in gimple? > >If I want to replace the uses of a variable with another one, do I >have to do this by hand, investigate the type of the instruction and >perform a replacement where necessary or is there any sort of helper >available? > >In llvm, this can be done with Value::replaceAllUsesWith(Value *V). You can replace all uses of an SSA name with replace_uses_by. Richard. >Thanks, >Cristina
Re: gnu-gabi group
On Thu, Feb 11, 2016 at 04:38:28PM +, Joseph Myers wrote: > 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. I like that idea. For elfutils we try to follow the various GNU gabi, ELF and DWARF extensions. Most extensions are independent of the linux kernel, and also work with kfreebsd or hurd (both of which have a Debian elfutils port). Having a central place to ask for clarifications and document these extensions would be great. We do maintain a list of GNU DWARF extensions: https://fedorahosted.org/elfutils/wiki/DwarfExtensions But don't have a good list of GNU gabi/ELF extensions. If we could ask overseers to setup a new group/list gnu-gabi on sourceware where binutils, gcc, gdb, glibc and other interested parties could join to maintain these extensions and ask for clarifications that would be wonderful. I am not a big fan of google groups mailinglists, they seem to make it hard to subscribe and don't have easy to access archives. Having a local gnu-gabi group on sourceware.org would be better IMHO. Cheers, Mark
gengtype: missing `tag' option (MELT branch)
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch (svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn merge -r227926:227945 ^/trunk
Notice that the merge above is quite small, and AFAIU did not touch any
gengtype related stuff.
But strangely, the merged build is failing in gengtype:
build/gengtype -v \
-r gtype.state
gengtype reading state file gtype.state;gengtype read 1085612 bytes.
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing `tag'
option for type `gimple'
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing `tag'
option for type `gimple'
gengtype write #1 gt-go-go-lang.h
gengtype write #2 gt-jit-dummy-frontend.h
gengtype write #3 gt-c-c-decl.h
gengtype write #4 gt-cp-tree.h
gengtype write #5 gt-fortran-f95-lang.h
gengtype write #6 gtype-desc.c
gengtype write #7 gtype-lto.h
gengtype write #8 gtype-java.h
gengtype write #9 gtype-ada.h
gengtype write #10 gtype-desc.h
gengtype wrote 10 files.
Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
/*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
{
meltobject_ptr_t discr;
gimple val;
operator melt_ptr_t ()
{
return reinterpret_cast(this);
}
}; /* end of meltgimple_st */
struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
{
gimple e_at;
melt_ptr_t e_va;
};
FWIW, the gcc/melt/generated/meltrunsup.h file did not change in the
MELT branch since long time ago.
Do you have any clues about what has changed in gengtype about these tag
options in GCC 6? Or about the gimple type?
Regards.
PS. Of course the bug is very probably in the MELT branch, but it has
been a long time since I dived into gengtype. I can't figure out the error.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Linux-abi group
H.J. Lu wrote: 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. Intel ABI allows abi for binary compatibility on intel machines - just copy bins no need to target compile. Linux ABI? linus already suggested this in even 1990's releases: warning: do not share your kernel headers with applications, they might abuse it and anyway software relying on it would break soon (be a waste of time) when new releases released i just noticed myself the BEST PROTECTION against the need of ABI: is a kernel that has abi inside and offers fast exported features on "well known unix interfaces" to what otherwise would make software "machine dependant, fallible, and short lived"
Re: Linux-abi group
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
Re: gengtype: missing `tag' option (MELT branch)
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
> Hello All,
>
> I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
> MELT
> branch & plugin.
>
> I am noticing a strange thing.
>
> I was able to merge GCC trunk svn rev. 227945 into the MELT branch
> (svn
> rev. 233352) without any issues.
>
> Now, I am trying to merge into the MELT branch
>
> svn merge -r227926:227945 ^/trunk
>
> Notice that the merge above is quite small, and AFAIU did not touch
> any
> gengtype related stuff.
>
> But strangely, the merged build is failing in gengtype:
>
>
> build/gengtype -v \
> -r gtype.state
> gengtype reading state file gtype.state;gengtype read 1085612 bytes.
> ../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing
> `tag'
> option for type `gimple'
> ../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing
> `tag'
> option for type `gimple'
> ../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing
> `tag'
> option for type `gimple'
> ../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing
> `tag'
> option for type `gimple'
> ../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing
> `tag'
> option for type `gimple'
> ../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:265: missing
> `tag'
> option for type `gimple'
> gengtype write #1 gt-go-go-lang.h
> gengtype write #2 gt-jit-dummy-frontend.h
> gengtype write #3 gt-c-c-decl.h
> gengtype write #4 gt-cp-tree.h
> gengtype write #5 gt-fortran-f95-lang.h
> gengtype write #6 gtype-desc.c
> gengtype write #7 gtype-lto.h
> gengtype write #8 gtype-java.h
> gengtype write #9 gtype-ada.h
> gengtype write #10 gtype-desc.h
> gengtype wrote 10 files.
>
>
> Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
> /*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
> struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
> {
> meltobject_ptr_t discr;
> gimple val;
> operator melt_ptr_t ()
> {
> return reinterpret_cast(this);
> }
> }; /* end of meltgimple_st */
>
> struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
> {
> gimple e_at;
> melt_ptr_t e_va;
> };
>
>
> FWIW, the gcc/melt/generated/meltrunsup.h file did not change in the
> MELT branch since long time ago.
>
> Do you have any clues about what has changed in gengtype about these
> tag
> options in GCC 6? Or about the gimple type?
In r227941, "gimple" changed meaning. It's no longer a pointer to a
statement; instead, it's now the statement struct itself (see e.g.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00765.html )
Try changing these to "gimple *".
Hope this is helpful
Dave
Re: gnu-gabi group
On Thu, Feb 11, 2016 at 04:38:28PM +, Joseph Myers wrote: > 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. I like that idea. For elfutils we try to follow the various GNU gabi, ELF and DWARF extensions. Most extensions are independent of the linux kernel, and also work with kfreebsd or hurd (both of which have a Debian elfutils port). Having a central place to ask for clarifications and document these extensions would be great. We do maintain a list of GNU DWARF extensions: https://fedorahosted.org/elfutils/wiki/DwarfExtensions But don't have a good list of GNU gabi/ELF extensions. If we could ask overseers to setup a new group/list gnu-gabi on sourceware where binutils, gcc, gdb, glibc and other interested parties could join to maintain these extensions and ask for clarifications that would be wonderful. I am not a big fan of google groups mailinglists, they seem to make it hard to subscribe and don't have easy to access archives. Having a local gnu-gabi group on sourceware.org would be better IMHO. I agree. gnu-gabi seems more appropriate than linux-abi.
Re: gengtype: missing `tag' option (MELT branch)
On 02/11/16 23:13, David Malcolm wrote:
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch
(svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn merge -r227926:227945 ^/trunk
Notice that the merge above is quite small, and AFAIU did not touch
any
gengtype related stuff.
But strangely, the merged build is failing in gengtype:
build/gengtype -v \
-r gtype.state
gengtype reading state file gtype.state;gengtype read 1085612 bytes.
../../gcc-melt-basile/gcc/melt/generated/meltrunsup.h:256: missing
`tag'
option for type `gimple'
Here are lines 252-267 of my gcc/melt/generated/meltrunsup.h
/*gtyctypebox gtyctyp #4 CTYPE_GIMPLE*/
struct GTY (()) meltgimple_st /* when MELTOBMAG_GIMPLE*/
{
meltobject_ptr_t discr;
gimple val;
operator melt_ptr_t ()
{
return reinterpret_cast(this);
}
}; /* end of meltgimple_st */
struct GTY (()) entrygimplemelt_st /* for MELTOBMAG_MAPGIMPLES*/
{
gimple e_at;
melt_ptr_t e_va;
};
In r227941, "gimple" changed meaning. It's no longer a pointer to a
statement; instead, it's now the statement struct itself (see e.g.
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00765.html )
Try changing these to "gimple *".
That surely helps a lot. My feeling is that such a drastic change might
justify a comment in gcc/coretypes.h (for those porting a plugin from
GCC 5 to newer versions of GCC)
Thanks, regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
