From ricardo_anguiano at mentor.com Fri Aug 3 21:29:40 2012 From: ricardo_anguiano at mentor.com (Ricardo Anguiano) Date: Fri, 3 Aug 2012 14:29:40 -0700 Subject: [cxx-abi-dev] Is http://sourcery.mentor.com/public/cxx-abi/abi.html the source for the most recent ABI? In-Reply-To: (Matthew Markland's message of "Thu, 26 Jul 2012 19:50:48 -0500") References: Message-ID: Matthew Markland writes: > One thing I've had on my mind... I don't know the base format the > document is kept in, The base format is mostly html. I'll followup with more detail shortly. > but would it be worth translating to something that could generate > printable documentation easier? Once it is updated, perhaps > translating it to Markdown? That's something that will be up to you and your fellow document maintainers. :) Thanks, -- Ricardo Anguiano Mentor Graphics/CodeSourcery Embedded Software Division +1-510-354-6774 From ricardo_anguiano at mentor.com Fri Aug 3 22:27:20 2012 From: ricardo_anguiano at mentor.com (Ricardo Anguiano) Date: Fri, 3 Aug 2012 15:27:20 -0700 Subject: [cxx-abi-dev] cxx-abi documents moved to github Message-ID: Folks, We've moved the C++ ABI Summary documents here: http://mentorembedded.github.com/cxx-abi/ The github URL for the project is located here: https://github.com/MentorEmbedded/cxx-abi/ As is standard for github project pages, all web content is in the gh-pages branch. Thanks, -- Ricardo Anguiano Mentor Graphics/CodeSourcery Embedded Software Division +1-510-354-6774 From rjmccall at apple.com Fri Aug 24 00:02:13 2012 From: rjmccall at apple.com (John McCall) Date: Thu, 23 Aug 2012 17:02:13 -0700 Subject: [cxx-abi-dev] A proposed proposal process for the Itanium ABI Message-ID: <8703818A-9A3C-42A4-8C71-E80131DA8955@apple.com> To all it may concern: In order to combat the ongoing bit-rot of the Itanium ABI specification, the folks at Mentor Graphics Sourcery Tools (n?e CodeSourcery) have moved the ABI documents to github. The github project page is here: https://github.com/MentorEmbedded/cxx-abi/ The living documents are here: http://mentorembedded.github.com/cxx-abi/ They've also blessed Matthew Markland and me with the magical powers necessary to update the documents. We see this as a sort of "editor"-like responsibility. Given that some editing needs to be done, but to avoid ruffling any feathers that can remain unruffled, we'd like to establish some basic rules of engagement. (n.b. ? I've cleared this email with Matthew, but any errors or perceived rudeness should be taken as mine alone.) I apologize for the abruptness, but: please do not respond to this message unless you're an Itanium-ABI tool implementor who feels that the proposed process is significantly mistaken and/or will tend to exclude you. Otherwise, while I'm sure that your university is indeed a leading contributor to research in collaborative review theory, or that your company's five year plan relies on a thousand promises that nobody ever made that you absolutely need our blessing for, or that you personally have a deep and passionate commitment to the C++ language that entitles you to a commanding seat at every table tangentially related to it? while I'm sure one or all of these things are true, I want to make it clear that the "votes" belong to implementors, because an ABI's not worth much if it's not really the consensus of its implementations. I have no doubt that everyone else's skills and opinions will help us to guide and maintain the ABI; right now, we need to make sure that everyone is on board. Here is our mission at a broad scale: if a user has two different C++ tools (probably compilers, but let's not constrain ourselves) that target the same platform and claim to support the Itanium ABI, then either: (1) the tools will interoperate correctly on correct code or (2) we'll have a really good reason why not and a feasible plan to fix it in future releases of the tools. This should apply whether the two tools are completely independent implementations or just two different versions of the same implementation. Here is our mission at a small scale: we want to develop and document the consensus among all the C++ implementors who use the ABI. Okay. As we see it, there are three classes of changes we can make: 1. An editorial change can be anything from a grammar / wording fix to a minor clarification of intent. The key here is that we feel that it's totally uncontroversial and settled. We won't bother notifying the list when we make this kind of update, but if you're interested, you can sign up at github for commit notifications. 2. A minor change might be a missing case (e.g. in the mangler) or any clarification which isn't obviously settled or uncontroversial. For these, we will make a point of notifying the list when making any changes. For missing cases in particular, we will make an effort to make sure that the change is consistent with what seems to be current practice. If there's significant divergence, we will post to the list for guidance before pushing anything into the document. I personally have access to many versions of clang, many versions of gcc, and an increasingly old version of EDG. If you would like me to consider your implementation when drafting or editing proposals, you should email me to make sure I can test it. :) 3. A major change is anything with a serious and potentially pervasive impact on the ABI. Given our mission, most such changes are likely ruled out; however, I am counting in this category anything which amounts to a major policy statement. For these issues, we will attempt to lead a conversation on the list and develop consensus, waiting at least two weeks from the initial proposal before making any changes to the live document. Anyone with a suggestion (or better yet, a patch) can just email Matt or me or both, and we'll try to, without undue delay, either push it into the repository or forward it to this list for discussion, as we think is appropriate by the above rubric. If you disagree with an emerging consensus, or if you feel that a previous change was mistaken or unfortunate, it is your responsibility to speak up. This is an open process, and it's nobody's full-time job; we're not going to conduct straw polls or ring doorbells. On an individual note, I will try not to let my role as maintainer of a specific implementation interfere with my role as editor of the general document. I think I've demonstrated in the past a willingness to change clang when we were the odd ones out or otherwise in the wrong. I hope that other implementors are willing to reciprocate. With all that said, we have something of a queue to get through. Let's treat this proposal itself as a major change; if you have objections, please bring them up as soon as possible so that we can work something out in the next few weeks. If we can all agree that this is a reasonable basic process, then we can get started. John. From daveed at edg.com Fri Aug 24 13:49:22 2012 From: daveed at edg.com (David Vandevoorde) Date: Fri, 24 Aug 2012 09:49:22 -0400 Subject: [cxx-abi-dev] A proposed proposal process for the Itanium ABI In-Reply-To: <8703818A-9A3C-42A4-8C71-E80131DA8955@apple.com> References: <8703818A-9A3C-42A4-8C71-E80131DA8955@apple.com> Message-ID: On Aug 23, 2012, at 8:02 PM, John McCall wrote: [...] > Here is our mission at a small scale: we want to develop and document > the consensus among all the C++ implementors who use the ABI. > > Okay. As we see it, there are three classes of changes we can make: > > 1. An editorial change can be anything from a grammar / wording fix to > a minor clarification of intent. The key here is that we feel that it's totally > uncontroversial and settled. We won't bother notifying the list when we > make this kind of update, but if you're interested, you can sign up at > github for commit notifications. Okay. (Though if you have to "clarify intent", maybe it wasn't all that settled.) > 2. A minor change might be a missing case (e.g. in the mangler) or any > clarification which isn't obviously settled or uncontroversial. For these, > we will make a point of notifying the list when making any changes. I assume that means _prior_ to making any changes? I.e., you won't commit changes to the document until "we" (this mailing list) have had a chance to react? > For missing cases in particular, we will make an effort to make sure that > the change is consistent with what seems to be current practice. If there's > significant divergence, we will post to the list for guidance before pushing > anything into the document. > > I personally have access to many versions of clang, many versions of gcc, > and an increasingly old version of EDG. If you would like me to consider > your implementation when drafting or editing proposals, you should email > me to make sure I can test it. :) (We'll be happy to get you our latest release.) > 3. A major change is anything with a serious and potentially pervasive > impact on the ABI. Given our mission, most such changes are likely > ruled out; however, I am counting in this category anything which > amounts to a major policy statement. For these issues, we will attempt > to lead a conversation on the list and develop consensus, waiting at > least two weeks from the initial proposal before making any changes > to the live document. I don't think a distinction between "minor" and "major" change is useful here. My preference would be for changes to be posted to this mailing list, and if you (Mark Markland and yourself, presumably) think there is consensus, you announce it will be committed unless someone raises an alarm within a short time (Mark Mitchell had a 2-week settlement policy in the past, which seemed just fine, but I'd have no objection to a 2-day policy either). > Anyone with a suggestion (or better yet, a patch) can just email Matt or me > or both, and we'll try to, without undue delay, either push it into the > repository or forward it to this list for discussion, as we think is appropriate > by the above rubric. Unless the change it truly editorial, I think patches/suggestions should go through the mailing first in all cases. > > If you disagree with an emerging consensus, or if you feel that a previous > change was mistaken or unfortunate, it is your responsibility to speak up. > This is an open process, and it's nobody's full-time job; we're not going to > conduct straw polls or ring doorbells. > > On an individual note, I will try not to let my role as maintainer of a specific > implementation interfere with my role as editor of the general document. > I think I've demonstrated in the past a willingness to change clang when > we were the odd ones out or otherwise in the wrong. I hope that other > implementors are willing to reciprocate. > > With all that said, we have something of a queue to get through. Let's treat > this proposal itself as a major change; if you have objections, please > bring them up as soon as possible so that we can work something out > in the next few weeks. If we can all agree that this is a reasonable basic > process, then we can get started. See above. Daveed From marklandm at acm.org Fri Aug 24 20:13:36 2012 From: marklandm at acm.org (Matthew Markland) Date: Fri, 24 Aug 2012 15:13:36 -0500 Subject: [cxx-abi-dev] Introduction... was Re: A proposed proposal process for the Itanium ABI Message-ID: All: At the risk of spamming the list I thought I should just do a quick introduction. My name is Matthew Markland (Matt is fine) and I currently work for Cray, Inc. as the owner of their C/C++ front-end in the Cray Compiling Environment (CCE) product. My interest in the ABI document is having an up-to-date document that can be a useful reference for all involved. I'm working on this process as an individual, not sponsored by my employer, but I expect this work to make my job easier in the long run. And I like to print out stuff, so I'd like to eventually see a document that can be formatted to print nicely. I look forward to working with everyone to improve the ABI documentation. Thanks. Matt -- ----------------------------- Matthew W Markland marklandm at acm.org From rjmccall at apple.com Fri Aug 24 22:12:53 2012 From: rjmccall at apple.com (John McCall) Date: Fri, 24 Aug 2012 15:12:53 -0700 Subject: [cxx-abi-dev] A proposed proposal process for the Itanium ABI In-Reply-To: References: <8703818A-9A3C-42A4-8C71-E80131DA8955@apple.com> Message-ID: <4117EAEC-4FBA-48B6-8F61-BDD9A1A969B7@apple.com> On Aug 24, 2012, at 6:49 AM, David Vandevoorde wrote: > On Aug 23, 2012, at 8:02 PM, John McCall wrote: > [...] >> Here is our mission at a small scale: we want to develop and document >> the consensus among all the C++ implementors who use the ABI. >> >> Okay. As we see it, there are three classes of changes we can make: >> >> 1. An editorial change can be anything from a grammar / wording fix to >> a minor clarification of intent. The key here is that we feel that it's totally >> uncontroversial and settled. We won't bother notifying the list when we >> make this kind of update, but if you're interested, you can sign up at >> github for commit notifications. > > Okay. (Though if you have to "clarify intent", maybe it wasn't all that settled.) I'm thinking here of places where the intent is obvious ? usually explicit ? in one portion of the document, but where the local wording is more obscure. That sort of thing is inevitable in specs, and it's certainly present in ours. >> 2. A minor change might be a missing case (e.g. in the mangler) or any >> clarification which isn't obviously settled or uncontroversial. For these, >> we will make a point of notifying the list when making any changes. > > I assume that means _prior_ to making any changes? I.e., you won't commit changes to the document until "we" (this mailing list) have had a chance to react? For something that seems like an addition ? like "how should we mangle such-and-such" ? yes, definitely. I was hoping that we could use a shorter review period for things that seemed minor, just to keep down the number of different proposals in-flight. Most of the uncontroversial minor changes that I have in mind are the back-log changes: everything we've talked about on the list in the last few years which hasn't yet made it into the document. I agree that it's probably not worth calling these out as a special, more streamlined process, though. >> For missing cases in particular, we will make an effort to make sure that >> the change is consistent with what seems to be current practice. If there's >> significant divergence, we will post to the list for guidance before pushing >> anything into the document. >> >> I personally have access to many versions of clang, many versions of gcc, >> and an increasingly old version of EDG. If you would like me to consider >> your implementation when drafting or editing proposals, you should email >> me to make sure I can test it. :) > > (We'll be happy to get you our latest release.) Thank you. >> 3. A major change is anything with a serious and potentially pervasive >> impact on the ABI. Given our mission, most such changes are likely >> ruled out; however, I am counting in this category anything which >> amounts to a major policy statement. For these issues, we will attempt >> to lead a conversation on the list and develop consensus, waiting at >> least two weeks from the initial proposal before making any changes >> to the live document. > > I don't think a distinction between "minor" and "major" change is useful here. > > My preference would be for changes to be posted to this mailing list, and if you (Mark Markland and yourself, presumably) think there is consensus, you announce it will be committed unless someone raises an alarm within a short time (Mark Mitchell had a 2-week settlement policy in the past, which seemed just fine, but I'd have no objection to a 2-day policy either). That seems fair. So, the process is: for any non-editorial changes, we'll make sure that it's sent out in advance. At some, when consensus seems to have developed (and for a lot of the back-log items, that will probably be "as part of the same email"), Mark or I will announce that it'll be committed after if there aren't any more objections. The period of time will vary according to how major we think the change is, but it'll never be less than two days, and it'll be at least two full weeks if there's been serious debate on the list (for back-log changes, this includes at the initial time of proposal). Furthermore, anyone can ask us to hold off while they investigate and/or draft a response. To make the lifetime of a proposal as clear as possible, we'll also signal the list after committing anything non-editorial, and we'll try not to have more than two proposals under discussion at once. John.