diff options
| author | Torne (Richard Coles) <torne@google.com> | 2014-08-12 13:47:38 +0100 |
|---|---|---|
| committer | Torne (Richard Coles) <torne@google.com> | 2014-08-12 13:47:38 +0100 |
| commit | 5f1c94371a64b3196d4be9466099bb892df9b88e (patch) | |
| tree | 60a287ed27d1328d7806d12433d789b66ad91805 /native_client_sdk | |
| parent | 43165a58c6167882aabb62f470c4e4d21f807d79 (diff) | |
| download | chromium_org-5f1c94371a64b3196d4be9466099bb892df9b88e.tar.gz | |
Merge from Chromium at DEPS revision 288042
This commit was generated by merge_to_master.py.
Change-Id: I583602ff16d735199f1810565c9296e970ce2854
Diffstat (limited to 'native_client_sdk')
119 files changed, 692 insertions, 1491 deletions
diff --git a/native_client_sdk/PRESUBMIT.py b/native_client_sdk/PRESUBMIT.py index ac9fd612e5..4fd79cce9a 100644 --- a/native_client_sdk/PRESUBMIT.py +++ b/native_client_sdk/PRESUBMIT.py @@ -40,11 +40,15 @@ def CheckChangeOnCommit(input_api, output_api): def GetPreferredTryMasters(project, change): return { - 'tryserver.chromium': { + 'tryserver.chromium.linux': { 'linux_nacl_sdk': set(['defaulttests']), 'linux_nacl_sdk_build': set(['defaulttests']), + }, + 'tryserver.chromium.win': { 'win_nacl_sdk': set(['defaulttests']), 'win_nacl_sdk_build': set(['defaulttests']), + }, + 'tryserver.chromium.mac': { 'mac_nacl_sdk': set(['defaulttests']), 'mac_nacl_sdk_build': set(['defaulttests']), } diff --git a/native_client_sdk/doc_generated/community/security-contest/contest-announcement.html b/native_client_sdk/doc_generated/community/security-contest/contest-announcement.html index 28195904bd..69c32f1692 100644 --- a/native_client_sdk/doc_generated/community/security-contest/contest-announcement.html +++ b/native_client_sdk/doc_generated/community/security-contest/contest-announcement.html @@ -24,7 +24,6 @@ security experts</em></a> in the world? Then submit an exploit to the Native Client Security contest and you could also win <a class="reference internal" href="/native-client/community/security-contest/contest-faq.html#contest-faq-prizes"><em>cash prizes</em></a>, not to mention bragging rights.</p> -<section id="what-it-is"> <h2 id="what-it-is">What it is</h2> <p><img alt="WHAT" src="/native-client/images/code-32.gif" /> This is a contest with the goal to test the security of Native Client.</p> <p>To participate, you will need to:</p> @@ -38,13 +37,11 @@ Client discussion group</li> <li><a class="reference external" href="https://code.google.com/p/nativeclient/issues">Report</a> the exploits you find to our team</li> </ul> -</section><section id="when"> <h2 id="when">When</h2> <p><img alt="WHEN" src="/native-client/images/calendar-32.gif" /> You can register for the contest on Wednesday, February 25th 2009. The contest will end on Tuesday, May 5th 2009 at 11:59:59 Pacific time. Sign up early to start reporting exploits as soon as possible.</p> -</section><section id="what-s-in-it-for-you"> <h2 id="what-s-in-it-for-you">What’s in it for you</h2> <p><img alt="PRIZES" src="/native-client/images/gift-32.gif" /> Participating in the contest means that you will engage with early stage research technology. In addition, your work will be @@ -66,10 +63,8 @@ five cash prizes, as well as the recognition of your peers.</p> <p class="first sidebar-title">Featured Video</p> <p>Watch a talk about Native Client at Stanford University.</p> <div class="last"><iframe width="640" height="360" src="//www.youtube.com/embed/L8m9U7p_Ntk?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div></div> -</section><section id="forum-native-client-announce"> <h2 id="forum-native-client-announce">Forum: native-client-announce</h2> -<iframe src="https://groups.google.com/forum/embed/?place=forum/native-client-announce&showsearch=false&showtabs=false&theme=default&hideforumtitle=true&hidesubject=false&showpopout=true&parenturl=https%3A%2F%2Fdevelopers.google.com%2Fnative-client%2Fcommunity%2Fsecurity-contest%2Fcontest-announcement" scrolling="no" frameborder="1" width="768" height="512"></iframe></section><section id="forum-native-client-discuss"> -<h2 id="forum-native-client-discuss">Forum: native-client-discuss</h2> -<iframe src="https://groups.google.com/forum/embed/?place=forum/native-client-discuss&showsearch=false&showtabs=false&theme=default&hideforumtitle=true&hidesubject=false&showpopout=true&parenturl=https%3A%2F%2Fdevelopers.google.com%2Fnative-client%2Fcommunity%2Fsecurity-contest%2Fcontest-announcement" scrolling="no" frameborder="1" width="768" height="512"></iframe></section></section> +<iframe src="https://groups.google.com/forum/embed/?place=forum/native-client-announce&showsearch=false&showtabs=false&theme=default&hideforumtitle=true&hidesubject=false&showpopout=true&parenturl=https%3A%2F%2Fdevelopers.google.com%2Fnative-client%2Fcommunity%2Fsecurity-contest%2Fcontest-announcement" scrolling="no" frameborder="1" width="768" height="512"></iframe><h2 id="forum-native-client-discuss">Forum: native-client-discuss</h2> +<iframe src="https://groups.google.com/forum/embed/?place=forum/native-client-discuss&showsearch=false&showtabs=false&theme=default&hideforumtitle=true&hidesubject=false&showpopout=true&parenturl=https%3A%2F%2Fdevelopers.google.com%2Fnative-client%2Fcommunity%2Fsecurity-contest%2Fcontest-announcement" scrolling="no" frameborder="1" width="768" height="512"></iframe></section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/community/security-contest/contest-faq.html b/native_client_sdk/doc_generated/community/security-contest/contest-faq.html index 40ef1b79f9..e1aed53a3c 100644 --- a/native_client_sdk/doc_generated/community/security-contest/contest-faq.html +++ b/native_client_sdk/doc_generated/community/security-contest/contest-faq.html @@ -59,20 +59,16 @@ contest rules, see the Terms and Conditions.</p> <li><a class="reference internal" href="#why-is-my-country-province-excluded-from-the-contest" id="id44">Why is my country/province excluded from the contest?</a></li> </ul> -</div><section id="what-is-this-contest-about"> -<h2 id="what-is-this-contest-about">What is this contest about?</h2> +</div><h2 id="what-is-this-contest-about">What is this contest about?</h2> <p>We launched this contest in order to help make Native Client more secure. We invite participants to discover security bugs in our technology in order to compete to win cash prizes.</p> -</section><section id="where-can-i-get-more-information-on-native-client"> <h2 id="where-can-i-get-more-information-on-native-client">Where can I get more information on Native Client?</h2> <p>You can read our <a class="reference external" href="http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/34913.pdf">research paper</a> (PDF) or visit the site for the <a class="reference external" href="http://code.google.com/p/nativeclient">Native Client open-source project</a>.</p> -</section><section id="what-people-are-you-looking-for"> <h2 id="what-people-are-you-looking-for">What people are you looking for?</h2> <p>We are not looking for any particular participant profile. Everyone who is eligible to participate based on the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a> of the contest can sign up.</p> -</section><section id="how-do-i-sign-up"> <h2 id="how-do-i-sign-up">How do I sign up?</h2> <p>The first thing you need to do is to register. Then you and your team members (if any) will receive an email from our team asking you to @@ -82,7 +78,6 @@ Client issue tracker. You should not submit any bugs as part of your contest entries until everyone on your team has accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>, as those bugs will not be eligible for consideration in the contest.</p> -</section><section id="what-is-the-process-of-participating"> <h2 id="what-is-the-process-of-participating">What is the process of participating?</h2> <p>After you register yourself or your team and every member of your team has accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>, download @@ -93,18 +88,15 @@ first reported by yourself or your team. Before the end of the contest, you will need to submit a summary with the top 10 exploits you identified. Our judges will review submitted summaries and will select the top 5 contestants.</p> -</section><section id="how-many-prizes-are-there-what-are-the-prizes"> -<span id="contest-faq-prizes"></span><h2 id="how-many-prizes-are-there-what-are-the-prizes"><span id="contest-faq-prizes"></span>How many prizes are there? What are the prizes?</h2> +<h2 id="how-many-prizes-are-there-what-are-the-prizes"><span id="contest-faq-prizes"></span>How many prizes are there? What are the prizes?</h2> <p>There are five cash prizes: The first prize is $8,192, the second prize $4,096, the third prize is $2,048, the fourth prize is $1,024 and the fifth prize is $1,024. All amounts are in USD.</p> -</section><section id="can-i-sign-up-as-a-team-how-many-people-can-be-a-member-of-my-team"> <h2 id="can-i-sign-up-as-a-team-how-many-people-can-be-a-member-of-my-team">Can I sign up as a team? How many people can be a member of my team?</h2> <p>You can sign up as a team. There is no limit to how many people can participate in your team. However we recommend that you keep the size of your team small so as to be able to better coordinate during the contest.</p> -</section><section id="what-will-i-need-to-do-to-win"> <h2 id="what-will-i-need-to-do-to-win">What will I need to do to win?</h2> <p>To participate, you will need to test the Native Client builds, identify security exploits which affect the current Native Client @@ -114,7 +106,6 @@ participants selected by the judges and satisfy the requirements for eligibility, then you will win a cash prize. For more information on how to participate and how your entry will be evaluated please review our detailed <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section><section id="who-is-going-to-judge-these-entries-who-are-these-people"> <h2 id="who-is-going-to-judge-these-entries-who-are-these-people">Who is going to judge these entries? Who are these people?</h2> <p>Google has recruited a group of distinguished security experts to serve as judges for this contest:</p> @@ -131,32 +122,27 @@ serve as judges for this contest:</p> </ul> <p>Check out the <a class="reference internal" href="/native-client/community/security-contest/index.html#contest-judges"><em>Judges info</em></a> to learn more about their careers and contributions to the security community.</p> -</section><section id="when-can-i-start-submitting-issues"> <h2 id="when-can-i-start-submitting-issues">When can I start submitting issues?</h2> <p>You can start submitting issues after you and your team members (if any) have completed the registration process and accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section><section id="registration-does-not-work-for-me-what-can-i-do"> <h2 id="registration-does-not-work-for-me-what-can-i-do">Registration does not work for me—what can I do?</h2> <p>We recommend that you post this problem at the Google Group. Once you do so, a member from our team will reach out to you to try to diagnose the issue. We will try to help you out; keep in mind though that we can not be responsible for the inability of a participant to register.</p> -</section><section id="i-registered-as-a-team-but-i-want-to-change-the-team-composition-by-adding-or-removing-members-what-should-i-do"> <h2 id="i-registered-as-a-team-but-i-want-to-change-the-team-composition-by-adding-or-removing-members-what-should-i-do">I registered as a team but I want to change the team composition by adding or removing members. What should I do?</h2> <p>Please reply to one of the registration email messages you received (it should be sent to <a class="reference external" href="mailto:nacl-security-contest%40google.com">nacl-security-contest<span>@</span>google<span>.</span>com</a>) and indicate the changes you’d like to make. Please note that neither the team name nor team membership can be changed once all members have accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section><section id="i-have-a-previous-engagement-and-i-cannot-sign-up-until-after-the-competition-starts-is-this-ok"> <h2 id="i-have-a-previous-engagement-and-i-cannot-sign-up-until-after-the-competition-starts-is-this-ok">I have a previous engagement and I cannot sign up until after the competition starts. Is this ok?</h2> <p>You can sign up until the last day of the contest May 5th, 2009. However, keep in mind that while you can submit bugs through the Native Client Issue Tracker, none of these will be taken into account unless you (and all your team members) have completed the registration process prior to submitting any bugs.</p> -</section><section id="my-team-has-accepted-the-terms-and-conditions-except-for-one-person-who-is-unavailable-whose-email-was-misspelled-etc-what-can-i-do"> <h2 id="my-team-has-accepted-the-terms-and-conditions-except-for-one-person-who-is-unavailable-whose-email-was-misspelled-etc-what-can-i-do">My team has accepted the Terms and Conditions except for one person who is unavailable / whose email was misspelled / etc. What can I do?</h2> <p>To make edits to your team’s composition, or to update the contact information of a team member, you will need to reply to one of the @@ -168,12 +154,10 @@ composition and asking them to re-accept the <a class="reference internal" href= Conditions</em></a>. All team members will need to re-accept the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a> for the team to be considered as active.</p> -</section><section id="can-i-enter-multiple-times"> <h2 id="can-i-enter-multiple-times">Can I enter multiple times?</h2> <p>No, you cannot enter multiple times. If you register as an individual you can not also register on a team and if you are on a team you can not also be on another team.</p> -</section><section id="why-do-you-need-a-prize-recipient"> <h2 id="why-do-you-need-a-prize-recipient">Why do you need a prize recipient?</h2> <p>Google will not be responsible for the division of any prize money between members of a potential winning team. Instead Google will @@ -181,7 +165,6 @@ deliver the prize to one member indicated by the team. The team is solely responsible for managing the logistics of distributing the prize among team members. This is why Google asks all participating teams to identify a prize recipient.</p> -</section><section id="we-want-to-change-the-prize-recipient-what-can-we-do"> <h2 id="we-want-to-change-the-prize-recipient-what-can-we-do">We want to change the prize recipient. What can we do?</h2> <p>To make edits to the prize recipient before all team members have accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>, you will @@ -194,7 +177,6 @@ asking them to re-accept the <a class="reference internal" href="/native-client/ considered registered. After all team members have accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>, there can be no changes to the prize recipient.</p> -</section><section id="i-want-to-remain-anonymous-during-the-contest-is-this-possible"> <h2 id="i-want-to-remain-anonymous-during-the-contest-is-this-possible">I want to remain anonymous during the contest. Is this possible?</h2> <p>Yes. However, you will still need to provide us with your email address to register. After the contest ends and if you are one of the @@ -202,13 +184,10 @@ top 5 participants, to claim your prize, you and all of your team members (if any) will need to submit to Google all necessary tax and legal information that Google will need to comply with US and international legal and tax regulations.</p> -</section><section id="one-of-my-professors-friends-is-a-judge-can-i-participate"> <h2 id="one-of-my-professors-friends-is-a-judge-can-i-participate">One of my professors / friends is a judge. Can I participate?</h2> <p>Yes, you can participate.</p> -</section><section id="can-my-company-be-registered-as-an-entrant"> <h2 id="can-my-company-be-registered-as-an-entrant">Can my company be registered as an entrant?</h2> <p>No, this is not possible under our <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section><section id="i-never-signed-up-for-this-contest-but-i-got-an-email-from-you-what-is-this-about"> <h2 id="i-never-signed-up-for-this-contest-but-i-got-an-email-from-you-what-is-this-about">I never signed up for this contest, but I got an email from you. What is this about?</h2> <p>You have probably received an e-mail identifying you as a member of team that another person has created. In our email, we identified the @@ -218,7 +197,6 @@ person’s team, then accept the <a class="reference internal" href="/native do not wish to participate in the contest or you want to do so as a member of a different team, then you can remove yourself from the list of team members of that particular team.</p> -</section><section id="i-tried-to-sign-up-and-it-seems-someone-who-wants-to-be-a-member-of-my-team-has-already-registered-with-another-team-what-can-we-do"> <h2 id="i-tried-to-sign-up-and-it-seems-someone-who-wants-to-be-a-member-of-my-team-has-already-registered-with-another-team-what-can-we-do">I tried to sign up and it seems someone who wants to be a member of my team has already registered with another team. What can we do?</h2> <p>If everyone in your potential teammate’s original team (including himself/herself) has accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a> of the contest, then unfortunately you will have to @@ -232,11 +210,9 @@ composition and asking them to re-accept the <a class="reference internal" href= Conditions</em></a>. All team members of that team will need to re-accept the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a> for that team to be considered as active.</p> -</section><section id="i-lost-or-never-got-the-email-asking-me-to-confirm-the-terms-and-conditions-what-can-i-do"> <h2 id="i-lost-or-never-got-the-email-asking-me-to-confirm-the-terms-and-conditions-what-can-i-do">I lost or never got the email asking me to confirm the Terms and Conditions. What can I do?</h2> <p>Don’t worry, just send us an email at <a class="reference external" href="mailto:nacl-security-contest%40google.com">nacl-security-contest<span>@</span>google<span>.</span>com</a> and we will send you the link you need.</p> -</section><section id="one-of-our-team-members-rejected-the-terms-and-conditions-what-can-we-do"> <h2 id="one-of-our-team-members-rejected-the-terms-and-conditions-what-can-we-do">One of our team members rejected the Terms and Conditions. What can we do?</h2> <p>Your team is now considered to be invalid. If this rejection happened by accident, please restart the registration process. If it was @@ -245,21 +221,17 @@ accept the <a class="reference internal" href="/native-client/community/security participate in the contest unless they have accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a> and no team can participate unless all team members have accepted the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section><section id="how-are-you-going-to-evaluate-the-submissions"> <h2 id="how-are-you-going-to-evaluate-the-submissions">How are you going to evaluate the submissions?</h2> <p>The judges will evaluate each Summary based on the following criteria: a) Quality (Severity, Scope, Reliability and Style) and b) Quantity. Please review the judging criteria in the contest <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a> for more information.</p> -</section><section id="can-i-include-issues-i-submitted-before-the-contest"> <h2 id="can-i-include-issues-i-submitted-before-the-contest">Can I include issues I submitted before the contest?</h2> <p>No, you can not.</p> -</section><section id="what-is-the-difference-between-exploit-issue-and-summary"> <h2 id="what-is-the-difference-between-exploit-issue-and-summary">What is the difference between exploit, issue and summary?</h2> <p>An exploit becomes an issue once you submit it through the Native Client issue tracker. A summary can include multiple issues but not more than 10.</p> -</section><section id="what-issues-should-i-include-in-the-summary"> <h2 id="what-issues-should-i-include-in-the-summary">What issues should I include in the summary?</h2> <p>You should include a maximum of 10 issues that you and your team members (if any) submitted to the Native Client Issue tracker. We @@ -269,30 +241,25 @@ more likely to be perceived as high impact from our judges and could help you win one of the five cash prizes. Do not include issues that have been marked as duplicates or unverifiable, as these will not be taken into account by our judges.</p> -</section><section id="why-are-you-asking-for-the-top-10-issues-only"> <h2 id="why-are-you-asking-for-the-top-10-issues-only">Why are you asking for the top 10 issues only?</h2> <p>We want to make sure that we use our judges’ time wisely. Rather than having them review hundreds of similar or small scale bugs, sometimes identified with the same automatic process, we are limiting the number of issues that each participant can submit in his/her/their summary.</p> -</section><section id="my-english-is-not-great-will-this-count-against-me-in-the-judging-process"> <h2 id="my-english-is-not-great-will-this-count-against-me-in-the-judging-process">My English is not great—will this count against me in the judging process?</h2> <p>Entries in languages other than in English or entries that are deemed incomprehensible by the judges will not be reviewed. We do not plan to penalize summaries for spelling or grammar mistakes, but please make your descriptions as clear as possible.</p> -</section><section id="what-information-do-i-need-to-include-in-the-issue-submission"> <h2 id="what-information-do-i-need-to-include-in-the-issue-submission">What information do I need to include in the issue submission?</h2> <p>Please review the “Minimum requirements for issues” section of contest’s <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>. You will find a list of all the information you will need to include in every submitted issue. Failure to provide this information might make the submitted issue invalid for the purposes of this contest.</p> -</section><section id="how-do-i-contest-a-decision-that-a-bug-is-a-duplicate"> <h2 id="how-do-i-contest-a-decision-that-a-bug-is-a-duplicate">How do I contest a decision that a bug is a duplicate?</h2> <p>Please highlight this in our Google Group and a member of our team will get in touch with you.</p> -</section><section id="why-is-the-native-client-team-updating-the-source-code-during-the-contest"> <h2 id="why-is-the-native-client-team-updating-the-source-code-during-the-contest">Why is the Native Client team updating the source code during the contest?</h2> <p>We are updating Native Client’s source code to fix bugs reported by contest participants or exploits identified by our team. Our goal is @@ -301,11 +268,9 @@ from exploits that could damage their system. In addition, by updating our builds, we will be providing you with more opportunities to find new security bugs. Finally, we believe this will make the contest more interesting by continuously raising the bar of bug finding.</p> -</section><section id="i-forgot-to-include-something-in-the-summary-what-can-i-do"> <h2 id="i-forgot-to-include-something-in-the-summary-what-can-i-do">I forgot to include something in the summary—what can I do?</h2> <p>If the contest has not ended, you may submit an updated summary. You may not submit an updated summary once the contest has ended.</p> -</section><section id="someone-from-our-team-submitted-a-summary-on-behalf-of-our-team-without-consulting-with-everyone-else-how-can-we-ensure-that-the-judges-will-use-the-previous-summary-and-not-the-last-one"> <h2 id="someone-from-our-team-submitted-a-summary-on-behalf-of-our-team-without-consulting-with-everyone-else-how-can-we-ensure-that-the-judges-will-use-the-previous-summary-and-not-the-last-one">Someone from our team submitted a summary on behalf of our team without consulting with everyone else. How can we ensure that the judges will use the previous summary and not the last one?</h2> <p>If your team member submitted his / her version of the team’s summary before the end date of the contest, and if this is the last summary @@ -313,15 +278,12 @@ that was submitted from your team, then the Judges will disregard all previous versions of your summary and will only review this last one. If the contest has not ended, you may resubmit a previous summary to override the first.</p> -</section><section id="will-you-be-evaluating-each-exploit-separately-for-every-one-of-the-criteria"> <h2 id="will-you-be-evaluating-each-exploit-separately-for-every-one-of-the-criteria">Will you be evaluating each exploit separately for every one of the criteria?</h2> <p>We will use our criteria to evaluate submitted summaries, not individual exploits.</p> -</section><section id="i-only-found-one-exploit-but-i-think-it-is-very-good-can-i-still-win"> <h2 id="i-only-found-one-exploit-but-i-think-it-is-very-good-can-i-still-win">I only found one exploit but I think it is very good. Can I still win?</h2> <p>Yes. Quantity is only one of the criteria we use to evaluate submitted summaries.</p> -</section><section id="how-are-you-going-to-pick-the-winners"> <h2 id="how-are-you-going-to-pick-the-winners">How are you going to pick the winners?</h2> <p>After the contest ends, all submitted Summaries will be judged by a panel of at least three judges. The judges will evaluate each Summary @@ -333,13 +295,11 @@ will then be evaluated by all Judges using the same Criteria, and the top five Summaries will be selected as potential winners. For more information on the judging criteria and the judging process please review the relevant section of the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section><section id="when-and-how-are-we-going-to-find-out-the-results-of-the-contest"> <h2 id="when-and-how-are-we-going-to-find-out-the-results-of-the-contest">When and how are we going to find out the results of the contest?</h2> <p>We will contact all prospective winners at the email address provided to us at the registration process. You may request a list of winners after December 7th, 2009 by writing to: Native Client Security Contest Google Inc. 1600 Amphitheater Parkway Mountain View, CA 94043 USA</p> -</section><section id="what-will-google-do-with-my-data"> <h2 id="what-will-google-do-with-my-data">What will Google do with my data?</h2> <p>The personal data you provided to Google during the Contest will be stored and processed in the US within the context of the Contest. We @@ -350,17 +310,14 @@ number in the event you qualify for a prize. You have a right to access and withdraw your personal data. To exercise this right, you may write to: Native Client Security Contest, Google Inc., 1600 Amphitheater Parkway, Mountain View, CA 94043, USA.</p> -</section><section id="i-have-more-questions-where-can-i-get-a-response"> <h2 id="i-have-more-questions-where-can-i-get-a-response">I have more questions—where can I get a response?</h2> <p>We recommend to ask any additional questions you might have in the Google Group. Members from our team will be monitoring the group and will respond to your question there, to benefit other contest participants.</p> -</section><section id="i-like-this-project-are-you-hiring-people-to-work-on-it-full-time"> <h2 id="i-like-this-project-are-you-hiring-people-to-work-on-it-full-time">I like this project. Are you hiring people to work on it full time?</h2> <p>At Google we are always looking for great people. Please review our current openings at www.google.com/jobs.</p> -</section><section id="how-can-i-get-involved-in-this-project-besides-the-contest"> <h2 id="how-can-i-get-involved-in-this-project-besides-the-contest">How can I get involved in this project besides the contest?</h2> <p>Thank you for your interest in Native Client. You can help us by:</p> <ul class="small-gap"> @@ -369,7 +326,6 @@ current openings at www.google.com/jobs.</p> <li>Writing apps</li> </ul> <p>We would also like to see you participate in our discussion group.</p> -</section><section id="why-is-my-country-province-excluded-from-the-contest"> <h2 id="why-is-my-country-province-excluded-from-the-contest">Why is my country/province excluded from the contest?</h2> <p>While we seek to make this contest open worldwide, we cannot open it to residents of Cuba, Iran, Syria, North Korea, Sudan, or Myanmar @@ -377,6 +333,6 @@ to residents of Cuba, Iran, Syria, North Korea, Sudan, or Myanmar residents of Brazil, Italy, or Quebec because of local restrictions. For more information on eligibility, see the <a class="reference internal" href="/native-client/community/security-contest/contest-terms.html"><em>Terms and Conditions</em></a>.</p> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/community/security-contest/index.html b/native_client_sdk/doc_generated/community/security-contest/index.html index dd80024c27..2ebe1d83f9 100644 --- a/native_client_sdk/doc_generated/community/security-contest/index.html +++ b/native_client_sdk/doc_generated/community/security-contest/index.html @@ -24,7 +24,6 @@ experts who served as judges.</p> welcomes your continued involvement in the project. You can help by submitting bugs and participating in the Native Client discussion group.</p> -<section id="contest-overview"> <h2 id="contest-overview">Contest overview</h2> <p>The Native Client team held a contest in 2009 to test the security of Native Client and help make the system more secure. Participants were @@ -40,8 +39,7 @@ mention bragging rights.</div></blockquote> <p>The contest judges evaluated exploits designed to defeat Native Client security measures based on severity, scope, reliability, and style. The winning teams and entries are listed below.</p> -</section><section id="contest-winners"> -<span id="id1"></span><h2 id="contest-winners"><span id="id1"></span>Contest winners</h2> +<h2 id="contest-winners"><span id="id1"></span>Contest winners</h2> <p>The Native Client team thanks everyone who participated in the contest for their contributions to improving the quality and security of the Native Client system. The judges reviewed the submitted exploits and @@ -117,11 +115,9 @@ Native Client through Google Summer of Code.</p> </tr> </tbody> </table> -</section><section id="panel-of-judges"> -<span id="contest-judges"></span><h2 id="panel-of-judges"><span id="contest-judges"></span>Panel of judges</h2> +<h2 id="panel-of-judges"><span id="contest-judges"></span>Panel of judges</h2> <p>Google recruited the following group of distinguished security experts to serve as judges for the Native Client security contest:</p> -<section id="chair"> <h3 id="chair">Chair</h3> <table border="1" class="docutils"> <colgroup> @@ -135,7 +131,6 @@ to serve as judges for the Native Client security contest:</p> </tr> </tbody> </table> -</section><section id="judges"> <h3 id="judges">Judges</h3> <table border="1" class="docutils"> <colgroup> @@ -179,7 +174,6 @@ to serve as judges for the Native Client security contest:</p> </tr> </tbody> </table> -</section></section><section id="additional-information"> <h2 id="additional-information">Additional information</h2> <p>For additional information about the Native Client security contest, see the archived @@ -196,6 +190,6 @@ and participate in the Native Client <li>Contribute to the <a class="reference external" href="http://code.google.com/p/nativeclient/">Native Client open-source project</a>.</li> </ul> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html b/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html index bfd391a1ba..c4503f10c3 100644 --- a/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html +++ b/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html @@ -13,7 +13,6 @@ with issues directly related to programming in the Native Client environment. To learn more about OpenGL ES 2.0 itself, see the <a class="reference external" href="http://opengles-book.com/">OpenGL ES 2.0 Programming Guide</a>. </aside> -<section id="validating-the-client-graphics-platform"> <h2 id="validating-the-client-graphics-platform">Validating the client graphics platform</h2> <p>Native Client is a software technology that lets you code an application once and run it on multiple platforms without worrying about the implementation @@ -25,7 +24,6 @@ to have vulnerabilities that can be exploited.</p> <p>Even if the GPU driver is safe to use, your program should perform a validation check before you launch your application to ensure that the driver supports all the features you need.</p> -<section id="vetting-the-driver-in-javascript"> <h3 id="vetting-the-driver-in-javascript">Vetting the driver in JavaScript</h3> <p>At startup, the application should perform a few additional tests that can be implemented in JavaScript on its hosting web page. The script that performs @@ -36,9 +34,7 @@ can, use the context to confirm the existence of any required OpenGL ES 2.0 extensions. You may want to refer to the <a class="reference external" href="http://www.khronos.org/registry/webgl/extensions/">extension registry</a> and include <a class="reference external" href="https://developer.mozilla.org/en-US/docs/WebGL/Using_Extensions">vendor prefixes</a> when checking for extensions.</p> -</section><section id="vetting-the-driver-in-native-client"> <h3 id="vetting-the-driver-in-native-client">Vetting the driver in Native Client</h3> -<section id="create-a-context"> <h4 id="create-a-context">Create a context</h4> <p>Once you’ve passed the JavaScript validation tests, it’s safe to add a Native Client embed tag to the hosting web page and load the module. As part of the @@ -50,7 +46,6 @@ the context, try creating a simpler version to see if you’re asking for an unsupported feature or exceeding a driver resource limit. Your production code should always check that the context was created and fail gracefully if that’s not the case.</p> -</section><section id="check-for-extensions-and-capabilities"> <h4 id="check-for-extensions-and-capabilities">Check for extensions and capabilities</h4> <p>Not every GPU supports every extension or has the same amount of texture units, vertex attributes, etc. On startup, call <code>glGetString(GL_EXTENSIONS)</code> and @@ -92,7 +87,6 @@ as well as texture and vertex data accordingly:</p> <code>glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, ...)</code> returns a value greater than or equal to the number of simultaneous textures you need.</li> </ul> -</section></section><section id="vetting-the-driver-in-the-chrome-web-store"> <h3 id="vetting-the-driver-in-the-chrome-web-store">Vetting the driver in the Chrome Web Store</h3> <p>If you choose to place your application in the <a class="reference external" href="/webstore">Chrome Web Store</a>, its Web Store <a class="reference external" href="/extensions/manifest">manifest file</a> can include the <code>webgl</code> @@ -120,7 +114,6 @@ been disabled.”</p> <p>The manifest-based check applies only to downloads directly from the Chrome Web Store. It is not performed when an application is loaded via <a class="reference external" href="/webstore/inline_installation">inline installation</a>.</p> -</section><section id="what-to-do-when-there-are-problems"> <h3 id="what-to-do-when-there-are-problems">What to do when there are problems</h3> <p>Using the vetting procedure described above, you should be able to detect the most common problems before your application runs. If there are problems, your @@ -131,7 +124,6 @@ might want to linke to the Chrome page that describes <a class="reference extern <p>If a user can’t update the driver, or their problem persists, be sure to gather information about their graphics environment. Ask for the contents of the Chrome <code>about:gpu</code> page.</p> -</section><section id="document-unreliable-drivers"> <h3 id="document-unreliable-drivers">Document unreliable drivers</h3> <p>It can be helpful to include information about known dubious drivers in your user documentation. This might help identify if a rogue driver is the cause of a @@ -140,7 +132,6 @@ found at the <a class="reference external" href="http://src.chromium.org/viewvc/ and <a class="reference external" href="http://www.khronos.org/webgl/wiki/BlacklistsAndWhitelists">Khronos</a>. You can use these lists to include information in your documentation that warns users about dangerous drivers.</p> -</section><section id="test-your-defenses"> <h3 id="test-your-defenses">Test your defenses</h3> <p>You can test your driver validation code by running Chrome with the following flags (all at once) and watching how your application responds:</p> @@ -151,10 +142,8 @@ flags (all at once) and watching how your application responds:</p> <li><code>--disable-accelerated-compositing</code></li> <li><code>--disable-accelerated-2d-canvas</code></li> </ul> -</section></section><section id="calling-opengl-es-2-0-commands"> <h2 id="calling-opengl-es-2-0-commands">Calling OpenGL ES 2.0 commands</h2> <p>There are three ways to write OpenGL ES 2.0 calls in Native Client.</p> -<section id="use-pure-opengl-es-2-0-function-calls"> <h3 id="use-pure-opengl-es-2-0-function-calls">Use “pure” OpenGL ES 2.0 function calls</h3> <p>You can make OpenGL ES 2.0 calls through a Pepper extension library. The SDK example <code>examples/api/graphics_3d</code> works this way. In the file @@ -200,7 +189,6 @@ bool InitGL(int32_t new_width, int32_t new_height) { necessary: upon application launch (when the graphics context is NULL) and whenever the module’s View changes size.</li> </ul> -</section><section id="use-regal"> <h3 id="use-regal">Use Regal</h3> <p>If you are porting an OpenGL ES 2.0 application, or are comfortable writing in OpenGL ES 2.0, you should stick with the Pepper APIs or pure OpenGL ES 2.0 calls @@ -211,7 +199,6 @@ Client. Regal forwards most OpenGL calls directly to the underlying graphics library, but it can also emulate other calls that are not included (when hardware support exists). See <a class="reference external" href="http://www.altdevblogaday.com/2012/09/04/bringing-regal-opengl-to-native-client/">libregal</a> for more info.</p> -</section><section id="use-the-pepper-api"> <h3 id="use-the-pepper-api">Use the Pepper API</h3> <p>Your code can call the Pepper PPB_OpenGLES2 API directly, as with any Pepper interface. When you write in this way, each invocation of an OpenGL ES 2.0 @@ -224,13 +211,11 @@ ppb_g3d_interface->CompileShader(graphicsContext, shader); <p>This approach specifically targets the Pepper APIs. Each call corresponds to a OpenGL ES 2.0 function, but the syntax is unique to Native Client, so the source file is not portable.</p> -</section></section><section id="implementing-a-rendering-loop"> <h2 id="implementing-a-rendering-loop">Implementing a rendering loop</h2> <p>Graphics applications require a continuous frame render-and-redraw cycle that runs at a high frequency. To achieve the best frame rate, is important to understand how the OpenGL ES 2.0 code in a Native Client module interacts with Chrome.</p> -<section id="the-chrome-and-native-client-processes"> <h3 id="the-chrome-and-native-client-processes">The Chrome and Native Client processes</h3> <p>Chrome is a multi-process browser. Each Chrome tab is a separate process that is running an application with its own main thread (we’ll call it the Chrome main @@ -246,7 +231,6 @@ a standstill.</p> <p>Native Client uses callback functions to synchronize the main threads of the two processes. Only certain Pepper functions use callbacks; <a class="reference external" href="/native-client/pepper_stable/c/struct_p_p_b___graphics3_d__1__0#a293c6941c0da084267ffba3954793497">SwapBuffers</a> is one.</p> -</section><section id="swapbuffers-and-its-callback-function"> <h3 id="swapbuffers-and-its-callback-function"><code>SwapBuffers</code> and its callback function</h3> <p><code>SwapBuffers</code> is non-blocking; it is called from the Native Client thread and returns immediately. When <code>SwapBuffers</code> is called, it runs asynchronously on @@ -271,7 +255,6 @@ from the main thread to Native Client, green up-arrows are non-blocking <code>SwapBuffers</code> calls from Native Client to the main thread. All OpenGL ES 2.0 calls are made from <code>Draw</code> in the Native Client thread.</p> <img alt="/native-client/images/3d-graphics-render-loop.png" src="/native-client/images/3d-graphics-render-loop.png" /> -</section><section id="sdk-example-graphics-3d"> <h3 id="sdk-example-graphics-3d">SDK example <code>graphics_3d</code></h3> <p>The SDK example <code>graphics_3d</code> uses the function <code>MainLoop</code> (in <code>hello_world.cc</code>) to create a rendering loop as described above. <code>MainLoop</code> @@ -293,7 +276,6 @@ void MainLoop(void* foo, int bar) { } } </pre> -</section></section><section id="managing-the-opengl-es-2-0-pipeline"> <h2 id="managing-the-opengl-es-2-0-pipeline">Managing the OpenGL ES 2.0 pipeline</h2> <p>OpenGL ES 2.0 commands do not run in the Chrome or Native Client processes. They are passed into a FIFO queue in shared memory which is best understood as a <a class="reference external" href="http://www.chromium.org/developers/design-documents/gpu-command-buffer">GPU @@ -324,7 +306,6 @@ commands. For example, issue a flush before you begin any multithreaded particle work, so that the command buffer will be clear when you start doing OpenGL ES 2.0 calls again. Determining where and how often to call <code>glFlush</code> can be tricky, you will need to experiment to find the sweet spot.</p> -</section><section id="rendering-and-inactive-tabs"> <h2 id="rendering-and-inactive-tabs">Rendering and inactive tabs</h2> <p>Users will often switch between tabs in a multi-tab browser. A well-behaved application that’s performing 3D rendering should pause any real-time processing @@ -347,7 +328,6 @@ main thread every 30 msec or so. This provides time to update features that should still run in the background, like audio. It may also be helpful to call <code>sched_yield</code> or <code>usleep</code> on any worker threads to release resources and cede cycles to the OS.</p> -<section id="handling-tab-activation-from-the-main-thread"> <h3 id="handling-tab-activation-from-the-main-thread">Handling tab activation from the main thread</h3> <p>You can detect and respond to the activation or deactivation of a tab with JavaScript on your hosting page. Add an EventListener for <code>visibilitychange</code> @@ -364,7 +344,6 @@ document.addEventListener('visibilitychange', function(){ }, false); </pre> -</section><section id="handling-tab-activation-from-the-native-client-thread"> <h3 id="handling-tab-activation-from-the-native-client-thread">Handling tab activation from the Native Client thread</h3> <p>You can also detect and respond to the activation or deactivation of a tab directly from your Native Client module by including code in the function @@ -372,11 +351,9 @@ directly from your Native Client module by including code in the function module’s view occurs. The code can call <code>ppb::View::IsPageVisible</code> to determine if the page is visible or not. The most common cause of invisible pages is that the page is in a background tab.</p> -</section></section><section id="tips-and-best-practices"> <h2 id="tips-and-best-practices">Tips and best practices</h2> <p>Here are some suggestions for writing safe code and getting the maximum performance with the Pepper 3D API.</p> -<section id="do-s"> <h3 id="do-s">Do’s</h3> <ul class="small-gap"> <li><p class="first"><strong>Make sure to enable attrib 0.</strong> OpenGL requires that you enable attrib 0, @@ -408,7 +385,6 @@ transforms, avoid matrix-to-matrix conversions. For instance, upres a vec3 to a vec4 before transforming it by a mat4, rather than converting the mat4 to a mat3.</li> </ul> -</section><section id="don-ts"> <h3 id="don-ts">Don’ts</h3> <ul class="small-gap"> <li><strong>Don’t use client side buffers.</strong> OpenGL ES 2.0 can use client side data with @@ -436,6 +412,6 @@ avoid this problem, keep static and dynamic data in different buffers.</li> error. Each time it is called, an error messages will appear in Chrome’s <code>about:gpu</code> tab.</li> </ul> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/application-structure.html b/native_client_sdk/doc_generated/devguide/coding/application-structure.html index a11581f396..33912745ad 100644 --- a/native_client_sdk/doc_generated/devguide/coding/application-structure.html +++ b/native_client_sdk/doc_generated/devguide/coding/application-structure.html @@ -19,7 +19,6 @@ The “Hello, World” example is used here to illustrate basic Native Client programming techniques. You can find this code in the <em>/getting_started/part1</em> directory in the Native Client SDK download. </aside> -<section id="application-components"> <h2 id="application-components">Application components</h2> <p>A Native Client application typically contains the following components:</p> <ul class="small-gap"> @@ -37,8 +36,7 @@ architecture-specific executable files (with .nexe extensions).</li> <p>Applications that are published in the <a class="reference external" href="https://chrome.google.com/webstore/search?q=%22Native+Client%22+OR+NativeClient+OR+NaCl">Chrome Web Store</a> also include a Chrome Web Store manifest file <code>(manifest.json)</code> and one or more icon files.</p> -</section><section id="html-file-and-the-embed-element"> -<span id="html-file"></span><h2 id="html-file-and-the-embed-element"><span id="html-file"></span>HTML file and the <embed> element</h2> +<h2 id="html-file-and-the-embed-element"><span id="html-file"></span>HTML file and the <embed> element</h2> <p>The <code><embed></code> element in an HTML file triggers the loading of a Native Client module and specifies the rectangle on the web page that is managed by the module. Here is the <embed> element from the “Hello, World” application:</p> @@ -68,8 +66,7 @@ user’s computer (see the following section for more information)</dd> modules the type must be “application/x-pnacl”. For architecture-specific Native Client modules the type must be “application/x-nacl”</dd> </dl> -</section><section id="manifest-files"> -<span id="manifest-file"></span><h2 id="manifest-files"><span id="manifest-file"></span>Manifest Files</h2> +<h2 id="manifest-files"><span id="manifest-file"></span>Manifest Files</h2> <p>Native Client applications have two types of manifest files: a Chrome Web Store manifest file and a Native Client manifest file.</p> <p>A <strong>Chrome Web Store manifest file</strong> is a file with information about a web @@ -132,7 +129,6 @@ manifest files.</p> compilation step (see the Makefile in any of the SDK examples for an illustration of how to do so). The manifest file format is also <a class="reference internal" href="/native-client/reference/nacl-manifest-format.html"><em>documented</em></a>.</p> -</section><section id="modules-and-instances"> <h2 id="modules-and-instances">Modules and instances</h2> <p>A Native Client <strong>module</strong> is C or C++ code compiled into a PNaCl .pexe file or a NaCl .nexe file.</p> @@ -146,7 +142,6 @@ module may be included in a web page multiple times by using multiple <code><embed></code> elements that refer to the module; in this case the Native Client runtime system loads the module once and creates multiple instances that are managed by the module.</p> -</section><section id="native-client-modules-a-closer-look"> <h2 id="native-client-modules-a-closer-look">Native Client modules: A closer look</h2> <p>A Native Client module must include three components:</p> <ul class="small-gap"> @@ -212,6 +207,6 @@ issue a <code>crash</code> event samples shown above don’t actually do anything. Subsequent chapters in the Developer’s Guide build on these code samples and add more interesting functionality.</p> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/audio.html b/native_client_sdk/doc_generated/devguide/coding/audio.html index 8d06f97181..875ae1526f 100644 --- a/native_client_sdk/doc_generated/devguide/coding/audio.html +++ b/native_client_sdk/doc_generated/devguide/coding/audio.html @@ -38,7 +38,6 @@ starts playing the audio samples as soon as it is loaded into the browser. For a slightly more sophisticated example, see the <code>audio</code> example (source code in the SDK directory <code>examples/api/audio</code>), which lets users specify a frequency for the sine wave and click buttons to start and stop audio playback.</p> -<section id="reference-information"> <h2 id="reference-information">Reference information</h2> <p>For reference information related to the Pepper audio API, see the following documentation:</p> @@ -49,7 +48,6 @@ documentation:</p> <li><a class="reference external" href="/native-client/pepper_stable/cpp/audio_8h">audio.h</a></li> <li><a class="reference external" href="/native-client/pepper_stable/c/group___enums#gaee750c350655f2fb0fe04c04029e0ff8">PP_AudioSampleRate</a></li> </ul> -</section><section id="about-the-pepper-audio-api"> <h2 id="about-the-pepper-audio-api">About the Pepper audio API</h2> <p>The Pepper audio API lets Native Client modules play audio streams in a browser. To play an audio stream, a module generates audio samples and writes @@ -81,7 +79,6 @@ audio buffer.</li> <p>This basic interaction is illustrated below, and described in detail in the sections that follow.</p> <img alt="/native-client/images/pepper-audio-api.png" src="/native-client/images/pepper-audio-api.png" /> -</section><section id="digital-audio-concepts"> <h2 id="digital-audio-concepts">Digital audio concepts</h2> <p>Before you use the Pepper audio API, it’s helpful to understand a few concepts that are fundamental to how digital audio is recorded and played back:</p> @@ -110,7 +107,6 @@ with the following configurations:</p> <li><strong>bit depth</strong>: 16</li> <li><strong>channels</strong>: 2 (stereo)</li> </ul> -</section><section id="setting-up-the-module"> <h2 id="setting-up-the-module">Setting up the module</h2> <p>The code examples below describe a simple Native Client module that generates audio samples using a sine wave with a frequency of 440 Hz. The module starts @@ -153,9 +149,7 @@ class SineSynthModule : public pp::Module { } }; </pre> -</section><section id="creating-an-audio-configuration-resource"> <h2 id="creating-an-audio-configuration-resource">Creating an audio configuration resource</h2> -<section id="resources"> <h3 id="resources">Resources</h3> <p>Before the module can play an audio stream, it must create two resources: an audio configuration resource and an audio resource. Resources are handles to @@ -166,7 +160,6 @@ when the samples in the stream’s buffer run out. An audio configuration re is an object that stores configuration data for an audio resource, including the sampling frequency of the audio samples, and the number of samples that the callback function must provide when the browser invokes it.</p> -</section><section id="sample-frame-count"> <h3 id="sample-frame-count">Sample frame count</h3> <p>Prior to creating an audio configuration resource, the module should call <code>RecommendSampleFrameCount</code> to obtain a <em>sample frame count</em> from the @@ -192,7 +185,6 @@ the browser must invoke the callback function frequently to refill the audio buffer. Conversely, a large sample frame count results in higher latency but lower CPU usage. You should request a large sample frame count if your module will play long, uninterrupted audio segments.</p> -</section><section id="supported-audio-configurations"> <h3 id="supported-audio-configurations">Supported audio configurations</h3> <p>After the module obtains a sample frame count, it can create an audio configuration resource. Currently the Pepper audio API supports audio streams @@ -225,14 +217,12 @@ bool SineSynthInstance::Init(uint32_t argc, return audio_.StartPlayback(); } </pre> -</section></section><section id="creating-an-audio-resource"> <h2 id="creating-an-audio-resource">Creating an audio resource</h2> <p>Once the module has created an audio configuration resource, it can create an audio resource. To do so, it instantiates a <code>pp::Audio</code> object, passing in a pointer to the module instance, the audio configuration resource, a callback function, and a pointer to user data (data that is used in the callback function). See the example above.</p> -</section><section id="implementing-a-callback-function"> <h2 id="implementing-a-callback-function">Implementing a callback function</h2> <p>The browser calls the callback function associated with an audio resource every time it needs more samples to play. The callback function can generate new @@ -293,7 +283,6 @@ class SineSynthInstance : public pp::Instance { ... }; </pre> -<section id="application-threads-and-real-time-requirements"> <h3 id="application-threads-and-real-time-requirements">Application threads and real-time requirements</h3> <p>The callback function runs in a background application thread. This allows audio processing to continue even when the application is busy doing something @@ -325,7 +314,6 @@ callback function may not be called immediately after the call to another thread so that the audio stream starts playing simultaneously with another action in your application, you must handle such synchronization manually.</p> -</section></section><section id="starting-and-stopping-playback"> <h2 id="starting-and-stopping-playback">Starting and stopping playback</h2> <p>To start and stop audio playback, the module simply reacts to JavaScript messages.</p> @@ -347,6 +335,6 @@ void SineSynthInstance::HandleMessage(const pp::Var& var_message) { } } </pre> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/file-io.html b/native_client_sdk/doc_generated/devguide/coding/file-io.html index 6cb5734aba..ac784c51d4 100644 --- a/native_client_sdk/doc_generated/devguide/coding/file-io.html +++ b/native_client_sdk/doc_generated/devguide/coding/file-io.html @@ -35,8 +35,7 @@ </li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p>This chapter describes how to use the <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_file_i_o">FileIO API</a> to read and write files using a local secure data store.</p> <p>You might use the File IO API with the URL Loading APIs to create an overall @@ -53,7 +52,6 @@ application.</li> </ol> <p>The example discussed in this chapter is included in the SDK in the directory <code>examples/api/file_io</code>.</p> -</section><section id="reference-information"> <h2 id="reference-information">Reference information</h2> <p>For reference information related to FileIO, see the following documentation:</p> <ul class="small-gap"> @@ -64,7 +62,6 @@ a file reference or “weak pointer” to a file in a file system</li> <li><a class="reference external" href="/native-client/pepper_stable/cpp/file__system_8h">file_system.h</a> - API to create a file system associated with a file</li> </ul> -</section><section id="local-file-i-o"> <h2 id="local-file-i-o">Local file I/O</h2> <p>Chrome provides an obfuscated, restricted area on disk to which a web app can safely <a class="reference external" href="https://developers.google.com/chrome/whitepapers/storage#persistent">read and write files</a>. The @@ -74,8 +71,7 @@ files and manage caching yourself. The data is persistent between launches of Chrome, and is not removed unless your application deletes it or the user manually deletes it. There is no limit to the amount of local data you can use, other than the actual space available on the local drive.</p> -<section id="enabling-local-file-i-o"> -<span id="enabling-file-access"></span><span id="quota-management"></span><h3 id="enabling-local-file-i-o"><span id="enabling-file-access"></span><span id="quota-management"></span>Enabling local file I/O</h3> +<h3 id="enabling-local-file-i-o"><span id="enabling-file-access"></span><span id="quota-management"></span>Enabling local file I/O</h3> <p>The easiest way to enable the writing of persistent local data is to include the <a class="reference external" href="/extensions/declare_permissions#unlimitedStorage">unlimitedStorage permission</a> in your Chrome Web Store manifest file. With this permission you can use the Pepper FileIO API without @@ -86,7 +82,6 @@ JavaScript code that calls the <a class="reference external" href="http://update explicitly request local disk space before using the FileIO API. In this case Chrome will prompt the user to accept a requestQuota call every time one is made.</p> -</section><section id="testing-local-file-i-o"> <h3 id="testing-local-file-i-o">Testing local file I/O</h3> <p>You should be aware that using the <code>unlimitedStorage</code> manifest permission constrains the way you can test your app. Three of the four techniques @@ -97,7 +92,6 @@ If you want to test the file IO portion of your app with a simple local server, you need to include JavaScript code that calls the HTML5 Quota Management API. When you deliver your application you can replace this code with the <code>unlimitedStorage</code> manifest permission.</p> -</section></section><section id="the-file-io-example"> <h2 id="the-file-io-example">The <code>file_io</code> example</h2> <p>The Native Client SDK includes an example, <code>file_io</code>, that demonstrates how to read and write a local disk file. Since you will probably run the example @@ -115,7 +109,6 @@ Native Client module.</li> </ul> <p>The remainder of this section covers the code in the <code>file_io.cc</code> file for reading and writing files.</p> -<section id="file-i-o-overview"> <h3 id="file-i-o-overview">File I/O overview</h3> <p>Like many Pepper APIs, the File IO API includes a set of methods that execute asynchronously and that invoke callback functions in your Native Client module. @@ -129,7 +122,6 @@ your worker thread, so you can use the stack and standard control flow structures normally.</p> <p>The high-level flow for the <code>file_io</code> example is described below. Note that methods in the namespace <code>pp</code> are part of the Pepper C++ API.</p> -</section><section id="creating-and-writing-a-file"> <h3 id="creating-and-writing-a-file">Creating and writing a file</h3> <p>Following are the high-level steps involved in creating and writing to a file:</p> @@ -142,7 +134,6 @@ blocked until the call to <code>Write</code> completes. If there is more data to write, <code>Write</code> is called again.</li> <li>When there is no more data to write, call <code>pp::FileIO::Flush</code>.</li> </ol> -</section><section id="opening-and-reading-a-file"> <h3 id="opening-and-reading-a-file">Opening and reading a file</h3> <p>Following are the high-level steps involved in opening and reading a file:</p> <ol class="arabic simple"> @@ -155,15 +146,12 @@ its file size. The thread is blocked until <code>Query</code> completes.</li> until <code>Read</code> completes. If there is more data to read, <code>Read</code> is called again.</li> </ol> -</section><section id="deleting-a-file"> <h3 id="deleting-a-file">Deleting a file</h3> <p>Deleting a file is straightforward: call <code>pp::FileRef::Delete</code>. The thread is blocked until <code>Delete</code> completes.</p> -</section><section id="making-a-directory"> <h3 id="making-a-directory">Making a directory</h3> <p>Making a directory is also straightforward: call <code>pp::File::MakeDirectory</code>. The thread is blocked until <code>MakeDirectory</code> completes.</p> -</section><section id="listing-the-contents-of-a-directory"> <h3 id="listing-the-contents-of-a-directory">Listing the contents of a directory</h3> <p>Following are the high-level steps involved in listing a directory:</p> <ol class="arabic simple"> @@ -175,7 +163,6 @@ its callback, so it must be specified.</li> <code>ListCallback</code> which packages up the results into a string message, and sends it to JavaScript.</li> </ol> -</section></section><section id="file-io-deep-dive"> <h2 id="file-io-deep-dive"><code>file_io</code> deep dive</h2> <p>The <code>file_io</code> example displays a user interface with a couple of fields and several buttons. Following is a screenshot of the <code>file_io</code> example:</p> @@ -185,7 +172,6 @@ default values for filenames. Try typing a message in the large input box and clicking <code>Save</code>, then switching to the <code>Load File</code> operation, and clicking <code>Load</code>.</p> <p>Let’s take a look at what is going on under the hood.</p> -<section id="opening-a-file-system-and-preparing-for-file-i-o"> <h3 id="opening-a-file-system-and-preparing-for-file-i-o">Opening a file system and preparing for file I/O</h3> <p><code>pp::Instance::Init</code> is called when an instance of a module is created. In this example, <code>Init</code> starts a new thread (via the <code>pp::SimpleThread</code> @@ -226,7 +212,6 @@ void OpenFileSystem(int32_t /*result*/) { } } </pre> -</section><section id="handling-messages-from-javascript"> <h3 id="handling-messages-from-javascript">Handling messages from JavaScript</h3> <p>When you click the <code>Save</code> button, JavaScript posts a message to the NaCl module with the file operation to perform sent as a string (See <a class="reference internal" href="/native-client/devguide/coding/message-system.html"><em>Messaging @@ -260,7 +245,6 @@ virtual void HandleMessage(const pp::Var& var_message) { } } </pre> -</section><section id="saving-a-file"> <h3 id="saving-a-file">Saving a file</h3> <p><code>FileIoInstance::Save</code> is called when the <code>Save</code> button is pressed. First, it checks to see that the FileSystem has been successfully opened:</p> @@ -324,7 +308,6 @@ if (flush_result != PP_OK) { return; } </pre> -</section><section id="loading-a-file"> <h3 id="loading-a-file">Loading a file</h3> <p><code>FileIoInstance::Load</code> is called when the <code>Load</code> button is pressed. Like the <code>Save</code> function, <code>Load</code> first checks to see if the FileSystem has been @@ -394,7 +377,6 @@ std::string string_data(data.begin(), data.end()); PostMessage("DISP|" + string_data); ShowStatusMessage("Load success"); </pre> -</section><section id="id1"> <h3 id="id1">Deleting a file</h3> <p><code>FileIoInstance::Delete</code> is called when the <code>Delete</code> button is pressed. First, it checks whether the FileSystem has been opened, and creates a new @@ -420,7 +402,6 @@ if (result == PP_ERROR_FILENOTFOUND) { return; } </pre> -</section><section id="listing-files-in-a-directory"> <h3 id="listing-files-in-a-directory">Listing files in a directory</h3> <p><code>FileIoInstance::List</code> is called when the <code>List Directory</code> button is pressed. Like all other operations, it checks whether the FileSystem has been @@ -470,7 +451,6 @@ void ListCallback(int32_t result, ShowStatusMessage("List success"); } </pre> -</section><section id="making-a-new-directory"> <h3 id="making-a-new-directory">Making a new directory</h3> <p><code>FileIoInstance::MakeDir</code> is called when the <code>Make Directory</code> button is pressed. Like all other operations, it checks whether the FileSystem has been @@ -492,6 +472,6 @@ if (result != PP_OK) { } ShowStatusMessage("Make directory success"); </pre> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/message-system.html b/native_client_sdk/doc_generated/devguide/coding/message-system.html index ef09cdf3d1..a93ab07751 100644 --- a/native_client_sdk/doc_generated/devguide/coding/message-system.html +++ b/native_client_sdk/doc_generated/devguide/coding/message-system.html @@ -43,7 +43,6 @@ The “Hello, World” example for getting started with NaCl is used her illustrate basic programming techniques. You can find this code in the <code>/getting_started/part2</code> directory in the Native Client SDK download. </aside> -<section id="reference-information"> <h2 id="reference-information">Reference information</h2> <p>For reference information related to the Pepper messaging API, see the following documentation:</p> @@ -53,7 +52,6 @@ HandleMessage(), PostMessage())</li> <li><a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_module">pp::Module class</a></li> <li><a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_var">pp::Var class</a></li> </ul> -</section><section id="introduction-to-the-messaging-system"> <h2 id="introduction-to-the-messaging-system">Introduction to the messaging system</h2> <p>Native Client modules and JavaScript communicate by sending messages to each other. The most basic form of a message is a string. Messages support many @@ -81,7 +79,6 @@ messages are:</p> </ul> <p>If you want to receive messages from JavaScript, you need to implement the <code>pp::Instance::HandleMessage()</code> function in your Native Client module.</p> -<section id="design-of-the-messaging-system"> <h3 id="design-of-the-messaging-system">Design of the messaging system</h3> <p>The Native Client messaging system is analogous to the system used by the browser to allow web workers to communicate (see the <a class="reference external" href="http://www.w3.org/TR/workers">W3 web @@ -103,12 +100,10 @@ avoiding the following problems:</p> than a few moments.</li> <li>The application hangs while waiting for an unresponsive Native Client module.</li> </ul> -</section></section><section id="communication-tasks-in-the-hello-world-example"> <h2 id="communication-tasks-in-the-hello-world-example">Communication tasks in the “Hello, World” example</h2> <p>The following sections describe how the “Hello, World” example posts and handles messages on both the JavaScript side and the Native Client side of the application.</p> -<section id="javascript-code"> <h3 id="javascript-code">JavaScript code</h3> <p>The JavaScript code and HTML in the “Hello, World” example can be found in the <code>example.js</code>, <code>common.js</code>, and <code>index.html</code> files. @@ -121,7 +116,6 @@ incoming <code>message</code> events.</li> <li>Calls <code>postMessage()</code> to communicate with the NaCl module, after the page loads.</li> </ol> -<section id="step-1-from-common-js"> <h4 id="step-1-from-common-js">Step 1: From common.js</h4> <pre class="prettyprint"> function attachDefaultListeners() { @@ -134,7 +128,6 @@ function attachDefaultListeners() { // ... } </pre> -</section><section id="step-2-from-example-js"> <h4 id="step-2-from-example-js">Step 2: From example.js</h4> <pre class="prettyprint"> // This function is called by common.js when a message is received from the @@ -152,7 +145,6 @@ function handleMessage(message) { <div id="log"></div> </body> </pre> -</section><section id="step-3-from-example-js"> <h4 id="step-3-from-example-js">Step 3: From example.js</h4> <pre class="prettyprint"> // From example.js, Step 3: @@ -164,7 +156,6 @@ function moduleDidLoad() { common.naclModule.postMessage('hello'); } </pre> -</section></section><section id="native-client-module"> <h3 id="native-client-module">Native Client module</h3> <p>The C++ code in the Native Client module of the “Hello, World” example:</p> <ol class="arabic simple"> @@ -201,16 +192,13 @@ class HelloTutorialInstance : public pp::Instance { } }; </pre> -</section></section><section id="messaging-in-javascript-code-more-details"> <h2 id="messaging-in-javascript-code-more-details">Messaging in JavaScript code: More details.</h2> <p>This section describes in more detail the messaging system code in the JavaScript portion of the “Hello, World” example.</p> -<section id="setting-up-an-event-listener-and-handler"> <h3 id="setting-up-an-event-listener-and-handler">Setting up an event listener and handler</h3> <p>The following JavaScript code sets up an event listener for messages posted by the Native Client module. It then defines a message handler that simply logs the content of messages received from the module.</p> -<section id="setting-up-the-message-handler-on-load"> <h4 id="setting-up-the-message-handler-on-load">Setting up the ‘message’ handler on load</h4> <pre class="prettyprint"> // From common.js @@ -244,7 +232,6 @@ function attachDefaultListeners() { // ... } </pre> -</section><section id="implementing-the-handler"> <h4 id="implementing-the-handler">Implementing the handler</h4> <pre class="prettyprint"> // From example.js @@ -256,11 +243,9 @@ function handleMessage(message) { <p>Note that the <code>handleMessage()</code> function is handed a message_event containing <code>data</code> that you can display or manipulate in JavaScript. The “Hello, World” application simply logs this data to the <code>log</code> div.</p> -</section></section></section><section id="messaging-in-the-native-client-module-more-details"> <h2 id="messaging-in-the-native-client-module-more-details">Messaging in the Native Client module: More details.</h2> <p>This section describes in more detail the messaging system code in the Native Client module portion of the “Hello, World” example.</p> -<section id="implementing-handlemessage"> <h3 id="implementing-handlemessage">Implementing HandleMessage()</h3> <p>If you want the Native Client module to receive and handle messages from JavaScript, you need to implement a <code>HandleMessage()</code> function @@ -301,7 +286,6 @@ class HelloTutorialInstance : public pp::Instance { } }; </pre> -</section><section id="implementing-application-specific-functions"> <h3 id="implementing-application-specific-functions">Implementing application-specific functions</h3> <p>While the “Hello, World” example is very simple, your Native Client module will likely include application-specific functions to perform @@ -316,7 +300,6 @@ character to determine which command to execute. If the command is command is “uncompress”, then data to process is an already-compressed string. After processing the data asynchronously, the application then returns the result to JavaScript.</p> -</section><section id="sending-messages-back-to-the-javascript-code"> <h3 id="sending-messages-back-to-the-javascript-code">Sending messages back to the JavaScript code</h3> <p>The Native Client module sends messages back to the JavaScript code using <code>PostMessage()</code>. The Native Client module always returns @@ -326,7 +309,6 @@ end of the Native Client module’s <code>HandleMessage()</code> function:</ <pre class="prettyprint"> PostMessage(var_reply); </pre> -</section><section id="sending-and-receiving-other-pp-var-types"> <h3 id="sending-and-receiving-other-pp-var-types">Sending and receiving other <code>pp::Var</code> types</h3> <p>Besides strings, <code>pp::Var</code> can represent other types of JavaScript objects. For example, messages can be JavaScript objects. These @@ -370,6 +352,6 @@ virtual void HandleMessage(const pp::Var& var) { } } </pre> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/nacl_io.html b/native_client_sdk/doc_generated/devguide/coding/nacl_io.html index a351b9013f..757899a56f 100644 --- a/native_client_sdk/doc_generated/devguide/coding/nacl_io.html +++ b/native_client_sdk/doc_generated/devguide/coding/nacl_io.html @@ -15,8 +15,7 @@ <li><a class="reference internal" href="#reference-information" id="id6">Reference information</a></li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p><code>nacl_io</code> is a utility library that provides implementations of standard C APIs such as POSIX I/O (<code>stdio.h</code>) and BSD sockets (<code>sys/socket.h</code>). Its primary function is to allow code that uses these standard APIs to be @@ -58,7 +57,6 @@ types which are described in the table below:</p> </tr> </tbody> </table> -</section><section id="using-nacl-io"> <h2 id="using-nacl-io">Using nacl_io</h2> <p>Using nacl_io is mostly just a matter of using the standard POSIX C library functions. However, there are some steps required to initialize the library @@ -79,9 +77,7 @@ options are explained in the <a class="reference internal" href="/native-client/ thread. This is because the main Pepper thread does not support the blocking behavior needed by the POSIX I/O operations.</li> </ol> -</section><section id="the-nacl-io-demo"> <h2 id="the-nacl-io-demo">The nacl_io demo</h2> -<section id="building-and-running-the-demo"> <h3 id="building-and-running-the-demo">Building and running the demo</h3> <p>The demo application launches a Native Client module that mounts three file systems and displays a set of controls that let you work with them:</p> @@ -116,10 +112,8 @@ in the menu, and press the fclose button</li> <li>select the fread command, be sure the file /persistent/test is selected in the menu, enter a byte count, and press the fread button</li> </ol> -</section><section id="a-look-at-the-code"> <h3 id="a-look-at-the-code">A look at the code</h3> <p>The demo is written C and comprises three files.</p> -<section id="nacl-io-demo-c"> <h4 id="nacl-io-demo-c">nacl_io_demo.c</h4> <p>This is the demo’s main file. The code here creates and initializes the Native Client module instance. The Pepper function <code>Instance_DidCreate</code> initializes @@ -164,14 +158,12 @@ function domContentLoaded(name, tc, config, width, height) { messages sent from the html page and performs the specified file system operations. The logic for the worker thread is encoded in the other two files, described below.</p> -</section><section id="queue-c"> <h4 id="queue-c">queue.c</h4> <p>This file implements a circular queue that is used to receive messages from the browser UI to the Native Client module. The file system commands in the enqueued messages are executed on the worker thread. This keeps blocking calls (like fread) off the main Native Client thread, which is a good thing. The queue is initialized in nacl_io_demo.c <code>Instance_DidCreate</code>.</p> -</section><section id="handlers-c"> <h4 id="handlers-c">handlers.c</h4> <p>This file implements the stdio calls associated with the commands sent from the browser. There is a separate <code>Handle*</code> function for each command: fopen, @@ -211,7 +203,6 @@ int HandleFwrite(int num_params, char** params, char** output) { return 0; } </pre> -</section></section></section><section id="reference-information"> <h2 id="reference-information">Reference information</h2> <p>The example discussed here is included in the SDK in the directory <code>examples/demo/nacl_io_demo</code>.</p> @@ -220,6 +211,6 @@ Pepper API. For reference information related to the nacl_io interface see its header file in the SDK directory, located at <code>include/nacl_io/nacl_io.h</code>.</p> <p>For more about the HTML5 file system read the <a class="reference external" href="http://dev.w3.org/2009/dap/file-system/pub/FileSystem/">specification</a>.</p> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html b/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html index 9ab9561a51..eb0477bef0 100644 --- a/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html +++ b/native_client_sdk/doc_generated/devguide/coding/native-client-modules.html @@ -13,14 +13,12 @@ but depend on whether the module is written in C or C++.</p> <li><a class="reference internal" href="#id1" id="id4">Writing modules in C++</a></li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p>Native Client modules do not have a <code>main()</code> function. When a module loads, the Native Client runtime calls the code in the module to create an instance and initialize the interfaces for the APIs the module uses. This initialization sequence depends on whether the module is written in C or C++ and requires that you implement specific functions in each case.</p> -</section><section id="writing-modules-in-c"> <h2 id="writing-modules-in-c">Writing modules in C</h2> <p>The C API uses a prefix convention to show whether an interface is implemented in the browser or in a module. Interfaces starting with <code>PPB_</code> (which can be @@ -111,7 +109,6 @@ PP_EXPORT int32_t PPP_InitializeModule(PP_Module a_module_id, PPB_GetInterface g return PP_OK; } </pre> -</section><section id="id1"> <h2 id="id1">Writing modules in C++</h2> <p>When you implement a Native Client module in C++ you must include these components:</p> <ul class="small-gap"> @@ -173,6 +170,6 @@ how to send messages between JavaScript code and Native Client modules.</p> samples shown above don’t actually do anything. Subsequent documents in the Developer’s Guide build on these code samples and add more interesting functionality.</p> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/progress-events.html b/native_client_sdk/doc_generated/devguide/coding/progress-events.html index 59b9727049..b2a5e574fe 100644 --- a/native_client_sdk/doc_generated/devguide/coding/progress-events.html +++ b/native_client_sdk/doc_generated/devguide/coding/progress-events.html @@ -23,7 +23,6 @@ The load_progress example illustrates progress event handling. You can find this code in the <code>/examples/tutorial/load_progress/</code> directory in the Native Client SDK download. </aside> -<section id="module-loading-and-progress-events"> <h2 id="module-loading-and-progress-events">Module loading and progress events</h2> <p>The Native Client runtime reports a set of state changes during the module loading process by means of DOM progress events. This set of events is a direct @@ -257,7 +256,6 @@ illegal.</td> </table> <p>Errors that occur during loading are logged to the JavaScript console in Google Chrome (select the menu icon <img alt="menu-icon" src="/native-client/images/menu-icon.png" /> > Tools > JavaScript console).</p> -</section><section id="handling-progress-events"> <h2 id="handling-progress-events">Handling progress events</h2> <p>You should add event listeners in a <code><script></code> element to listen for these events before the <code><embed></code> element is parsed. For example, the following code @@ -299,7 +297,6 @@ listeners on outer elements (including the <code><body></code> element) to from inner elements. For more information, see the W3 specifications for <a class="reference external" href="http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture">event flow capture</a> and <a class="reference external" href="http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-registration">event listener registration</a>.</p> -</section><section id="displaying-load-status"> <h2 id="displaying-load-status">Displaying load status</h2> <p>One common response to progress events is to display the percentage of the module that has been loaded. In the load_progress example, when the <code>progress</code> @@ -323,7 +320,6 @@ function moduleLoadProgress(event) { } } </pre> -</section><section id="the-lasterror-attribute"> <h2 id="the-lasterror-attribute">The <code>lastError</code> attribute</h2> <p>The <code><embed></code> element has a <code>lastError</code> attribute that is set to an informative string whenever a load failure (an <code>error</code> or <code>abort</code> event) @@ -346,7 +342,6 @@ function moduleLoadError() { common.logMessage('error: ' + common.naclModule.lastError); } </pre> -</section><section id="the-readystate-attribute"> <h2 id="the-readystate-attribute">The <code>readyState</code> attribute</h2> <p>You can use the <code>readyState</code> attribute to monitor the loading process. This attribute is particularly useful if you don’t care about the details of @@ -413,7 +408,6 @@ the progress events are generated.</p> </body> </html> </pre> -</section><section id="the-exitstatus-attribute"> <h2 id="the-exitstatus-attribute">The <code>exitStatus</code> attribute</h2> <p>This read-only attribute is set if the application calls <code>exit(n)</code>, <code>abort()</code>, or crashes. Since NaCl modules are event handlers, there is no @@ -429,6 +423,6 @@ target architecture, and may change in the future. Applications should not rely on the <code>exitStatus</code> value being stable in these cases, but the value may nevertheless be useful for temporary debugging.</li> </ul> -</section></section> +</section> {{/partials.standard_nacl_api}} diff --git a/native_client_sdk/doc_generated/devguide/coding/url-loading.html b/native_client_sdk/doc_generated/devguide/coding/url-loading.html index 47b6e79466..6465d5edac 100644 --- a/native_client_sdk/doc_generated/devguide/coding/url-loading.html +++ b/native_client_sdk/doc_generated/devguide/coding/url-loading.html @@ -21,13 +21,11 @@ </li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p>This chapter describes how to use the <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_u_r_l_loader">URLLoader API</a> to load resources such as images and sound files from a server into your application.</p> <p>The example discussed in this chapter is included in the SDK in the directory <code>examples/api/url_loader</code>.</p> -</section><section id="reference-information"> <h2 id="reference-information">Reference information</h2> <p>For reference information related to loading data from URLs, see the following documentation:</p> @@ -39,7 +37,6 @@ following documentation:</p> <li><a class="reference external" href="/native-client/pepper_stable/cpp/url__response__info_8h">url_response_info.h</a> - Contains <code>URLResponse</code> class for examaning URL responses</li> </ul> -</section><section id="background"> <h2 id="background">Background</h2> <p>When a user launches your Native Client web application, Chrome downloads and caches your application’s HTML file, manifest file (.nmf), and Native Client @@ -51,7 +48,6 @@ application.</p> assets. To avoid being at the whim of the Chrome cache, however, you may want to use the <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_file_i_o">Pepper FileIO API</a> to write those assets to a persistent, sandboxed location on the user’s file system.</p> -</section><section id="the-url-loader-example"> <h2 id="the-url-loader-example">The <code>url_loader</code> example</h2> <p>The SDK includes an example called <code>url_loader</code> demonstrating downloading files from a server. This example has these primary files:</p> @@ -70,7 +66,6 @@ bulk of the work is done).</li> </ul> <p>The remainder of this document covers the code in the <code>url_loader.cc</code> and <code>url_loader_handler.cc</code> files.</p> -<section id="url-loading-overview"> <h3 id="url-loading-overview">URL loading overview</h3> <p>Like many Pepper APIs, the <code>URLLoader</code> API includes a set of methods that execute asynchronously and that invoke callback functions in your Native Client @@ -96,9 +91,7 @@ files and fast connections).</li> </ol> <p>The remainder of this document demonstrates how the previous steps are implemented in the <code>url_loader</code> example.</p> -</section></section><section id="url-loader-deep-dive"> <h2 id="url-loader-deep-dive"><code>url_loader</code> deep dive</h2> -<section id="setting-up-the-request"> <h3 id="setting-up-the-request">Setting up the request</h3> <p><code>HandleMessage</code> in <code>url_loader.cc</code> creates a <code>URLLoaderHandler</code> instance and passes it the URL of the asset to be retrieved. Then <code>HandleMessage</code> @@ -146,7 +139,6 @@ URLLoaderHandler::URLLoaderHandler(pp::Instance* instance, url_request_.SetRecordDownloadProgress(true); } </pre> -</section><section id="downloading-the-data"> <h3 id="downloading-the-data">Downloading the data</h3> <p><code>Start</code> in <code>url_loader_handler.cc</code> creates a callback (<code>cc</code>) using a <code>CompletionCallbackFactory</code>. The callback is passed to <code>Open</code> to be called @@ -219,12 +211,11 @@ in <code>PP_OK</code> or 0), all the bytes have been read for what has been downloaded, but more is to be downloaded (<code>PP_OK_COMPLETIONPENDING</code> or -1), or there is an error (less than -1). <code>OnRead</code> is called in the event of an error or <code>PP_OK</code>.</p> -</section><section id="displaying-a-result"> <h3 id="displaying-a-result">Displaying a result</h3> <p>OnRead calls <code>ReportResultAndDie</code> when either an error or <code>PP_OK</code> is returned to indicate streaming of file is complete. <code>ReportResultAndDie</code> then calls <code>ReportResult,</code> which calls <code>PostMessage</code> to send the result back to the HTML page.</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html b/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html index 991855eac0..f311110147 100644 --- a/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html +++ b/native_client_sdk/doc_generated/devguide/coding/view-focus-input-events.html @@ -34,7 +34,6 @@ ppapi_simple library that can be used to to implement most of the boiler plate. The <code>pi_generator</code> example in <code>/examples/demo/pi_generator</code> uses ppapi_simple to manage view change events and 2D graphics.</p> -<section id="overview"> <h2 id="overview">Overview</h2> <p>When a user interacts with the web page using a keyboard, mouse or some other input device, the browser generates input events. In a traditional web @@ -156,9 +155,7 @@ branches accordingly.</td> </table> <p>These interfaces are found in the <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_instance">pp::Instance class</a>. The sections below provide examples of how to handle these events.</p> -</section><section id="handling-browser-events"> <h2 id="handling-browser-events">Handling browser events</h2> -<section id="didchangeview"> <h3 id="didchangeview">DidChangeView()</h3> <p>In the <code>mouse_lock</code> example, <code>DidChangeView()</code> checks the previous size of instance’s rectangle versus the new size. It also compares @@ -195,7 +192,6 @@ void MouseLockInstance::DidChangeView(const pp::View& view) { <li><a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_image_data">pp::ImageData class</a></li> <li><a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_graphics2_d">pp::Graphics2D class</a></li> </ul> -</section><section id="didchangefocus"> <h3 id="didchangefocus">DidChangeFocus()</h3> <p><code>DidChangeFocus()</code> is called when you click inside or outside of a module’s instance in the web page. When the instance goes out @@ -208,13 +204,11 @@ void DidChangeFocus(bool focus) { // the instance. } </pre> -</section></section><section id="handling-input-events"> <h2 id="handling-input-events">Handling input events</h2> <p>Input events are events that occur when the user interacts with a module instance using the mouse, keyboard, or other input device (e.g., touch screen). This section describes how the <code>input_events</code> example handles input events.</p> -<section id="registering-a-module-to-accept-input-events"> <h3 id="registering-a-module-to-accept-input-events">Registering a module to accept input events</h3> <p>Before your module can handle these events, you must register your module to accept input events using <code>RequestInputEvents()</code> for mouse @@ -238,7 +232,6 @@ combination of flags that identify the class of events that the instance is requesting to receive. Input event classes are defined in the <a class="reference external" href="/native-client/pepper_stable/c/group___enums.html#gafe68e3c1031daa4a6496845ff47649cd">PP_InputEvent_Class</a> enumeration in <a class="reference external" href="/native-client/pepper_stable/c/ppb__input__event_8h">ppb_input_event.h</a>.</p> -</section><section id="determining-and-branching-on-event-types"> <h3 id="determining-and-branching-on-event-types">Determining and branching on event types</h3> <p>In a typical implementation, the <code>HandleInputEvent()</code> function determines the type of each event using the <code>GetType()</code> function found in the <code>InputEvent</code> @@ -330,7 +323,6 @@ following documentation:</p> <li><a class="reference external" href="/native-client/pepper_stable/c/classpp_1_1_wheel_input_event">pp::WheelInputEvent class</a></li> <li><a class="reference external" href="/native-client/pepper_stable/c/classpp_1_1_keyboard_input_event">pp::KeyboardInputEvent class</a></li> </ul> -</section><section id="threading-and-blocking"> <h3 id="threading-and-blocking">Threading and blocking</h3> <p><code>HandleInputEvent()</code> in this example runs on the main module thread. However, the bulk of the work happens on a separate worker thread (see @@ -338,6 +330,6 @@ However, the bulk of the work happens on a separate worker thread (see the <code>event_queue_</code> and the worker thread takes events from the <code>event_queue_</code>. This processing happens independently of the main thread, so as not to slow down the browser.</p> -</section></section></section> +</section> {{/partials.standard_nacl_api}} diff --git a/native_client_sdk/doc_generated/devguide/devcycle/building.html b/native_client_sdk/doc_generated/devguide/devcycle/building.html index f3afcf494b..93b307ce76 100644 --- a/native_client_sdk/doc_generated/devguide/devcycle/building.html +++ b/native_client_sdk/doc_generated/devguide/devcycle/building.html @@ -42,14 +42,12 @@ </li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p>This document describes how to build Native Client modules. It is intended for developers who have experience writing, compiling, and linking C and C++ code. If you haven’t read the Native Client <a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a> and <a class="reference internal" href="/native-client/devguide/tutorial/index.html"><em>Tutorial</em></a>, we recommend starting with those.</p> -<section id="target-architectures"> -<span id="id1"></span><h3 id="target-architectures"><span id="id1"></span>Target architectures</h3> +<h3 id="target-architectures"><span id="id1"></span>Target architectures</h3> <p>Portable Native Client (PNaCl) modules are written in C or C++ and compiled into an executable file ending in a <strong>.pexe</strong> extension using the PNaCl toolchain in the Native Client SDK. Chrome can load <strong>pexe</strong> files @@ -71,15 +69,13 @@ for multiple target architectures and how to generate manifest files, see the Makefiles included with the SDK examples.</p> <p>This section will mostly cover PNaCl, but also describes how to build <strong>nexe</strong> applications.</p> -</section><section id="c-libraries"> <h3 id="c-libraries">C libraries</h3> <p>The PNaCl SDK has a single choice of C library: <a class="reference external" href="http://sourceware.org/newlib/">newlib</a>.</p> <p>The Native Client SDK also has a GCC-based toolchain for building <strong>nexes</strong>. The GCC-based toolchain has support for two C libraries: <a class="reference external" href="http://sourceware.org/newlib/">newlib</a> and <a class="reference external" href="http://www.gnu.org/software/libc/">glibc</a>. See <a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html"><em>Dynamic Linking & Loading with glibc</em></a> for information about these libraries, including factors to help you decide which to use.</p> -</section><section id="c-standard-libraries"> -<span id="building-cpp-libraries"></span><h3 id="c-standard-libraries"><span id="building-cpp-libraries"></span>C++ standard libraries</h3> +<h3 id="c-standard-libraries"><span id="building-cpp-libraries"></span>C++ standard libraries</h3> <p>The PNaCl SDK can use either LLVM’s <a class="reference external" href="http://libcxx.llvm.org/">libc++</a> (the current default) or GCC’s <a class="reference external" href="http://gcc.gnu.org/libstdc++">libstdc++</a> (deprecated). The <code>-stdlib=[libc++|libstdc++]</code> command line argument can be used to @@ -90,7 +86,6 @@ features should work regardless of which standard library is used. The <code>-std=gnu++11</code> command line argument can be used to indicate which C++ language standard to use (<code>-std=c++11</code> often doesn’t work well because newlib relies on some GNU extensions).</p> -</section><section id="sdk-toolchains"> <h3 id="sdk-toolchains">SDK toolchains</h3> <p>The Native Client SDK includes multiple toolchains. It has one PNaCl toolchain and it has multiple GCC-based toolchains that are differentiated by target @@ -119,7 +114,6 @@ properly part of the toolchains but that you may find helpful in building and testing your application (e.g., the <code>create_nmf.py</code> script, which you can use to create a manifest file). </aside> -</section><section id="sdk-toolchains-versus-your-hosted-toolchain"> <h3 id="sdk-toolchains-versus-your-hosted-toolchain">SDK toolchains versus your hosted toolchain</h3> <p>To build NaCl modules, you must use one of the Native Client toolchains included in the SDK. The SDK toolchains use a variety of techniques to @@ -144,7 +138,6 @@ modules written in other programming languages, such as C#. But this document covers only compiling C and C++ code, using the toolchains provided in the SDK. </aside> -</section></section><section id="the-pnacl-toolchain"> <h2 id="the-pnacl-toolchain">The PNaCl toolchain</h2> <p>The PNaCl toolchain contains modified versions of the tools in the LLVM toolchain, as well as linkers and other tools from binutils. @@ -181,12 +174,10 @@ tools include:</p> </dl> <p>For the full list of tools, see the <code><NACL_SDK_ROOT>/toolchain/<platform>_pnacl/bin</code> directory.</p> -</section><section id="using-the-pnacl-tools-to-compile-link-debug-and-deploy"> <h2 id="using-the-pnacl-tools-to-compile-link-debug-and-deploy">Using the PNaCl tools to compile, link, debug, and deploy</h2> <p>To build an application with the PNaCl SDK toolchain, you must compile your code, link it, test and debug it, and then deploy it. This section goes over some examples of how to use the tools.</p> -<section id="compile"> <h3 id="compile">Compile</h3> <p>To compile a simple application consisting of <code>file1.cc</code> and <code>file2.cc</code> into <code>hello_world.pexe</code> with a single command, use the <code>pnacl-clang++</code> tool</p> @@ -252,7 +243,6 @@ choose is application-specific, you’ll therefore want to experiment with t value that you pass in: you’ll be trading off potential performance with <strong>pexe</strong> size and on-device translation speed.</dd> </dl> -</section><section id="create-a-static-library"> <h3 id="create-a-static-library">Create a static library</h3> <p>The <code>pnacl-ar</code> and <code>pnacl-ranlib</code> tools allow you to create a <strong>static</strong> library from a set of bitcode files, which can later be linked @@ -263,7 +253,6 @@ into the full application.</p> <NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-ranlib libfoo.a </pre> -</section><section id="link-the-application"> <h3 id="link-the-application">Link the application</h3> <p>The <code>pnacl-clang++</code> tool is used to compile applications, but it can also be used link together compiled bitcode and libraries into a @@ -293,7 +282,6 @@ to reduce the size of the final <strong>pexe</strong> as well as making it trans faster. If you want to use C++ exceptions you should use the <code>--pnacl-exceptions=sjlj</code> linker flag as explained in the <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#exception-handling"><em>exception handling</em></a> section of the C++ language support reference.</p> -</section><section id="finalizing-the-pexe-for-deployment"> <h3 id="finalizing-the-pexe-for-deployment">Finalizing the <strong>pexe</strong> for deployment</h3> <p>Typically you would run the application to test it and debug it if needed before deploying. See the <a class="reference internal" href="/native-client/devguide/devcycle/running.html"><em>running</em></a> documentation for how to run a PNaCl @@ -314,8 +302,7 @@ stripping out debug information and other metadata.</p> refer to the final version of the application before deployment. The <code>create_nmf.py</code> tool helps generate an <code>.nmf</code> file, but <code>.nmf</code> files can also be written by hand.</p> -</section><section id="compressing-the-pexe-for-deployment"> -<span id="pnacl-compress"></span><h3 id="compressing-the-pexe-for-deployment"><span id="pnacl-compress"></span>Compressing the <strong>pexe</strong> for deployment</h3> +<h3 id="compressing-the-pexe-for-deployment"><span id="pnacl-compress"></span>Compressing the <strong>pexe</strong> for deployment</h3> <p>Size compression is an optional step for deployment, and reduces the size of the <strong>pexe</strong> file that must be transmitted over the wire, resulting in faster download speed. The tool <code>pnacl-compress</code> applies compression strategies that @@ -339,7 +326,6 @@ configured for HTTP compression: both compressions are complementary. You’ want to configure your web server to gzip <strong>pexe</strong> files: the gzipped version of a compressed <strong>pexe</strong> file is smaller than the corresponding uncompressed <strong>pexe</strong> file by 7.5% to 10%.</p> -</section></section><section id="the-gnu-based-toolchains"> <h2 id="the-gnu-based-toolchains">The GNU-based toolchains</h2> <p>Besides the PNaCl toolchain, the Native Client SDK also includes modified versions of the tools in the standard GNU toolchain, including the GCC @@ -385,7 +371,6 @@ flags, e.g., you can specify <code>x86_64-nacl-gcc -m32</code> to compile a 32-b <li><prefix>strings</li> <li><prefix>strip</li> </ul> -<section id="compiling"> <h3 id="compiling">Compiling</h3> <p>Compiling files with the GNU-based toolchain is similar to compiling files with the PNaCl-based toolchain, except that the output is @@ -403,7 +388,6 @@ of -m32. Alternatively, you could also use the version of the compiler that targets the x86-64 architecture, i.e., <code>x86_64-nacl-gcc</code>.</p> <p>You should name executable modules with a <strong>.nexe</strong> filename extension, regardless of what platform you’re using.</p> -</section><section id="creating-libraries-and-linking"> <h3 id="creating-libraries-and-linking">Creating libraries and Linking</h3> <p>Creating libraries and linking with the GNU-based toolchain is similar to doing the same with the PNaCl toolchain. The relevant tools @@ -411,7 +395,6 @@ for creating <strong>static</strong> libraries are <code><prefix>ar</code> Linking can be done with <code><prefix>g++</code>. See the <a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html"><em>Dynamic Linking & Loading with glibc</em></a> section on how to create <strong>shared</strong> libraries.</p> -</section><section id="finalizing-a-nexe-for-deployment"> <h3 id="finalizing-a-nexe-for-deployment">Finalizing a <strong>nexe</strong> for deployment</h3> <p>Unlike the PNaCl toolchain, no separate finalization step is required for <strong>nexe</strong> files. The <strong>nexe</strong> files are always in a <strong>stable</strong> format. @@ -419,7 +402,6 @@ However, the <strong>nexe</strong> file may contain debug information and symbol which may make the <strong>nexe</strong> file larger than needed for distribution. To minimize the size of the distributed file, you can run the <code><prefix>strip</code> tool to strip out debug information.</p> -</section></section><section id="using-make"> <h2 id="using-make">Using make</h2> <p>This document doesn’t cover how to use <code>make</code>, but if you want to use <code>make</code> to build your Native Client module, you can base your Makefile on the @@ -486,7 +468,6 @@ numerous variables near the top (e.g., <code>CFLAGS</code>) that make it easy to customize the commands that are executed for your project and the options for each command.</p> <p>For details on how to use make, see the <a class="reference external" href="http://www.gnu.org/software/make/manual/make.html">GNU ‘make’ Manual</a>.</p> -</section><section id="libraries-and-header-files-provided-with-the-sdk"> <h2 id="libraries-and-header-files-provided-with-the-sdk">Libraries and header files provided with the SDK</h2> <p>The Native Client SDK includes modified versions of standard toolchain-support libraries, such as libpthread and libc, plus the relevant header files. @@ -558,10 +539,8 @@ examples for the order in which specific libraries should be listed.</li> </ul> </aside> -</section><section id="troubleshooting"> <h2 id="troubleshooting">Troubleshooting</h2> <p>Some common problems, and how to fix them:</p> -<section id="undefined-reference-error"> <h3 id="undefined-reference-error">“Undefined reference” error</h3> <p>An “undefined reference” error may indicate incorrect link order and/or missing libraries. For example, if you leave out <code>-lppapi</code> when @@ -584,14 +563,12 @@ The nacl_io library essentially does option (3) for you: It lets your code use POSIX-like file system calls, and implements the calls using various technologies (e.g., HTML5 file system, read-only filesystems that use URL loaders, or an in-memory filesystem).</p> -</section><section id="can-t-find-libraries-containing-necessary-symbols"> <h3 id="can-t-find-libraries-containing-necessary-symbols">Can’t find libraries containing necessary symbols</h3> <p>Here is one way to find the appropriate library for a given symbol:</p> <pre> <NACL_SDK_ROOT>/toolchain/<platform>_pnacl/bin/pnacl-nm -o \ toolchain/<platform>_pnacl/usr/lib/*.a | grep <MySymbolName> </pre> -</section><section id="pnacl-abi-verification-errors"> <h3 id="pnacl-abi-verification-errors">PNaCl ABI Verification errors</h3> <p>PNaCl has restrictions on what is supported in bitcode. There is a bitcode ABI verifier which checks that the application conforms to the ABI restrictions, @@ -618,6 +595,6 @@ LLVM ERROR: PNaCl ABI verification failed that are <a class="reference internal" href="/native-client/nacl-and-pnacl.html#when-to-use-nacl"><em>not supported by PNaCl</em></a>. If the problem you face is not listed as restricted, <a class="reference internal" href="/native-client/help.html#help"><em>let us know</em></a>!</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/devcycle/debugging.html b/native_client_sdk/doc_generated/devguide/devcycle/debugging.html index c1bf30e198..ddd55f2c9f 100644 --- a/native_client_sdk/doc_generated/devguide/devcycle/debugging.html +++ b/native_client_sdk/doc_generated/devguide/devcycle/debugging.html @@ -40,9 +40,7 @@ and measure your application’s performance.</p> </li> </ul> -</div><section id="diagnostic-information"> -<h2 id="diagnostic-information">Diagnostic information</h2> -<section id="viewing-process-statistics-with-the-task-manager"> +</div><h2 id="diagnostic-information">Diagnostic information</h2> <h3 id="viewing-process-statistics-with-the-task-manager">Viewing process statistics with the task manager</h3> <p>You can use Chrome’s Task Manager to display information about a Native Client application:</p> @@ -68,7 +66,6 @@ memory footprint. You can also see the rendering rate displayed as frames per second (FPS). Note that the computation of render frames can be performed in any process, but the rendering itself is always done in the top level application process, so look for the rendering rate there.</p> -</section><section id="controlling-the-level-of-native-client-error-and-warning-messages"> <h3 id="controlling-the-level-of-native-client-error-and-warning-messages">Controlling the level of Native Client error and warning messages</h3> <p>Native Client prints warning and error messages to stdout and stderr. You can increase the amount of Native Client’s diagnostic output by setting the @@ -78,9 +75,7 @@ following <a class="reference external" href="http://en.wikipedia.org/wiki/Envir <li>NACL_SRPC_DEBUG=[1-255] (use a higher number for more verbose debug output)</li> <li>NACLVERBOSITY=[1-255]</li> </ul> -</section></section><section id="basic-debugging"> <h2 id="basic-debugging">Basic debugging</h2> -<section id="writing-messages-to-the-javascript-console"> <h3 id="writing-messages-to-the-javascript-console">Writing messages to the JavaScript console</h3> <p>You can send messages from your C/C++ code to JavaScript using the PostMessage call in the <a class="reference internal" href="/native-client/devguide/coding/message-system.html"><em>Pepper messaging system</em></a>. When the @@ -88,7 +83,6 @@ JavaScript code receives a message, its message event handler can call <a class="reference external" href="https://developer.mozilla.org/en/DOM/console.log">console.log()</a> to write the message to the JavaScript <a class="reference external" href="/devtools/docs/console-api">console</a> in Chrome’s Developer Tools.</p> -</section><section id="debugging-with-printf"> <h3 id="debugging-with-printf">Debugging with printf</h3> <p>Your C/C++ code can perform inline printf debugging to stdout and stderr by calling fprintf() directly, or by using cover functions like these:</p> @@ -103,7 +97,6 @@ void errormsg(const char* pMsg){ </pre> <p>By default stdout and stderr will appear in Chrome’s stdout and stderr stream but they can also be redirected as described below.</p> -<section id="redirecting-output-to-log-files"> <h4 id="redirecting-output-to-log-files">Redirecting output to log files</h4> <p>You can redirect stdout and stderr to output files by setting these environment variables:</p> <ul class="small-gap"> @@ -123,7 +116,6 @@ variables to redirect output to a file, you must run Chrome with the <code>--no-sandbox</code> flag. You must also be careful that each variable points to a different file. </aside> -</section><section id="redirecting-output-to-the-javascript-console"> <h4 id="redirecting-output-to-the-javascript-console">Redirecting output to the JavaScript console</h4> <p>You can also cause output from printf statements in your C/C++ code to be relayed to the JavaScript side of your application through the Pepper messaging @@ -176,7 +168,6 @@ if your module prints and flushes frequently, or if it makes frequent Pepper calls to begin with (e.g., to render).</p> </li> </ol> -</section></section><section id="logging-calls-to-pepper-interfaces"> <h3 id="logging-calls-to-pepper-interfaces">Logging calls to Pepper interfaces</h3> <p>You can log all Pepper calls your module makes by passing the following flags to Chrome on startup:</p> @@ -187,8 +178,7 @@ to Chrome on startup:</p> begin with “ppb” (that is, the interfaces that are implemented by the browser and that your module calls). The <code>enable-logging</code> flag tells Chrome to log the calls to stderr.</p> -</section><section id="debugging-with-visual-studio"> -<span id="visual-studio"></span><h3 id="debugging-with-visual-studio"><span id="visual-studio"></span>Debugging with Visual Studio</h3> +<h3 id="debugging-with-visual-studio"><span id="visual-studio"></span>Debugging with Visual Studio</h3> <p>If you develop on a Windows platform you can use the <a class="reference internal" href="/native-client/devguide/devcycle/vs-addin.html"><em>Native Client Visual Studio add-in</em></a> to write and debug your code. The add-in defines new project platforms that let you run your module in two different modes: As a @@ -196,8 +186,7 @@ Pepper plugin and as a Native Client module. When running as a Pepper plugin you can use the built-in Visual Studio debugger. When running as a Native Client module Visual Studio will launch an instance of nacl-gdb for you and link it to the running code.</p> -</section><section id="debugging-with-nacl-gdb"> -<span id="using-gdb"></span><h3 id="debugging-with-nacl-gdb"><span id="using-gdb"></span>Debugging with nacl-gdb</h3> +<h3 id="debugging-with-nacl-gdb"><span id="using-gdb"></span>Debugging with nacl-gdb</h3> <p>The Native Client SDK includes a command-line debugger that you can use to debug Native Client modules. The debugger is based on the GNU debugger <a class="reference external" href="http://www.gnu.org/software/gdb/">gdb</a>, and is located at <code>toolchain/<platform>_x86_newlib/bin/x86_64-nacl-gdb</code> (where <em><platform></em> @@ -207,8 +196,7 @@ is the platform of your development machine: <code>win</code>, <code>mac</code>, whether built using newlib or glibc for x86-32, x86-64 or ARM. In the SDK, <code>i686-nacl-gdb</code> is an alias for <code>x86_64-nacl-gdb</code>, and the <code>newlib</code> and <code>glibc</code> toolchains both contain the same version of GDB.</p> -<section id="debugging-pnacl-pexes-with-pepper-35"> -<span id="debugging-pnacl-pexes"></span><h4 id="debugging-pnacl-pexes-with-pepper-35"><span id="debugging-pnacl-pexes"></span>Debugging PNaCl pexes (with Pepper 35+)</h4> +<h4 id="debugging-pnacl-pexes-with-pepper-35"><span id="debugging-pnacl-pexes"></span>Debugging PNaCl pexes (with Pepper 35+)</h4> <p>If you want to use GDB to debug a program that is compiled with the PNaCl toolchain, you must have a copy of the pexe from <strong>before</strong> running <code>pnacl-finalize</code>. The <code>pnacl-finalize</code> tool converts LLVM bitcode @@ -233,13 +221,15 @@ that copy in your application’s manifest file:</p> <pre class="prettyprint"> { "program": { - "pnacl-translate": { - "url": "release_version.pexe", - "optlevel": 2 - }, - "pnacl-debug": { - "url": "debug_version.bc", - "optlevel": 0 + "portable": { + "pnacl-translate": { + "url": "release_version.pexe", + "optlevel": 2 + }, + "pnacl-debug": { + "url": "debug_version.bc", + "optlevel": 0 + } } } } @@ -255,7 +245,6 @@ is that it is only guaranteed to work for the Chrome version that matches the SDK version. Developers who may have left the <code>--enable-nacl-debug</code> flag turned on may end up loading the debug copy of your application (which may or may not work, depending on their version of Chrome).</p> -</section><section id="debugging-pnacl-pexes-with-older-pepper-toolchains"> <h4 id="debugging-pnacl-pexes-with-older-pepper-toolchains">Debugging PNaCl pexes (with older Pepper toolchains)</h4> <p>If you want to use GDB to debug a program that is compiled with the PNaCl toolchain, you must convert the <code>pexe</code> file to a <code>nexe</code>. (You can skip @@ -304,8 +293,7 @@ version of the NaCl sandbox on your system, you can translate the might find it easier to translate the <code>pexe</code> to both <code>nexe</code> formats as described above. </aside> -</section><section id="running-nacl-gdb"> -<span id="id1"></span><h4 id="running-nacl-gdb"><span id="id1"></span>Running nacl-gdb</h4> +<h4 id="running-nacl-gdb"><span id="id1"></span>Running nacl-gdb</h4> <p>Before you start using nacl-gdb, make sure you can <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>build</em></a> your module and <a class="reference internal" href="/native-client/devguide/devcycle/running.html"><em>run</em></a> your application normally. This will verify that you have created all the required <a class="reference internal" href="/native-client/devguide/coding/application-structure.html"><em>application parts</em></a> (.html, .nmf, and .nexe files, shared @@ -525,7 +513,6 @@ comprehensive list of gdb commands. Note that you can abbreviate most commands to just their first letter (<code>b</code> for break, <code>c</code> for continue, and so on).</p> <p>To interrupt execution of your module, press <Ctrl-c>. When you’re done debugging, close the Chrome window and type <code>q</code> to quit gdb.</p> -</section></section></section><section id="debugging-with-other-tools"> <h2 id="debugging-with-other-tools">Debugging with other tools</h2> <p>If you cannot use the <a class="reference internal" href="#visual-studio"><em>Visual Studio add-in</em></a>, or you want to use a debugger other than nacl-gdb, you must manually build your module as a @@ -542,12 +529,11 @@ Plugin</a>. Note that starting with the <code>pepper_22</code> bundle, the NaCl SDK for Windows includes pre-built libraries and library source code, making it much easier to build a module into a .DLL.</p> -<section id="open-source-profiling-tools"> <h3 id="open-source-profiling-tools">Open source profiling tools</h3> <p>For the brave-hearted there are open source tools at <a class="reference external" href="http://www.chromium.org/nativeclient">Chromium.org</a> that describe how to do profiling on <a class="reference external" href="https://sites.google.com/a/chromium.org/dev/nativeclient/how-tos/profiling-nacl-apps-on-64-bit-windows">64-bit Windows</a> and <a class="reference external" href="http://www.chromium.org/nativeclient/how-tos/limited-profiling-with-oprofile-on-x86-64">Linux</a> machines.</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html b/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html index 8cad9b62a6..7de0c6ca36 100644 --- a/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html +++ b/native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html @@ -18,8 +18,7 @@ <li><a class="reference internal" href="#troubleshooting" id="id9">Troubleshooting</a></li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <aside class="caution"> Portable Native Client currently only supports static linking, and the only C library available for it is newlib. This page is only valid for @@ -29,8 +28,7 @@ dynamic linking. <p>This document describes how to create and deploy dynamically linked and loaded applications with the glibc library in the Native Client SDK. Before reading this document, we recommend reading <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building Native Client Modules</em></a></p> -<section id="c-standard-libraries-glibc-and-newlib"> -<span id="c-libraries"></span><h3 id="c-standard-libraries-glibc-and-newlib"><span id="c-libraries"></span>C standard libraries: glibc and newlib</h3> +<h3 id="c-standard-libraries-glibc-and-newlib"><span id="c-libraries"></span>C standard libraries: glibc and newlib</h3> <p>The Native Client SDK comes with two C standard libraries — glibc and newlib. These libraries are described in the table below.</p> <table border="1" class="docutils"> @@ -123,7 +121,6 @@ uses, even if the rest of an application is dynamically linked.</li> </ul> </aside> -</section><section id="sdk-toolchains"> <h3 id="sdk-toolchains">SDK toolchains</h3> <p>The Native Client SDK contains multiple toolchains, which are differentiated by <a class="reference internal" href="/native-client/devguide/devcycle/building.html#target-architectures"><em>target architecture</em></a> and C library:</p> @@ -165,7 +162,6 @@ toolchain that uses glibc is in <code>toolchain/win_x86_glibc</code>.</p> use a glibc toolchain. (Currently the only glibc toolchain is <code><platform>_x86_glibc</code>.) Note that you must build all code in your application with one toolchain. Code from multiple toolchains cannot be mixed.</p> -</section><section id="specifying-and-delivering-shared-libraries"> <h3 id="specifying-and-delivering-shared-libraries">Specifying and delivering shared libraries</h3> <p>One significant difference between newlib and glibc applications is that glibc applications must explicitly list and deploy the shared libraries that they @@ -186,7 +182,6 @@ those libraries in a Native Client <a class="reference internal" href="/native-c deploy the libraries along with the application. Instructions for how to build a dynamically linked Native Client application, generate a Native Client manifest (.nmf) file, and deploy an application are provided below.</p> -</section></section><section id="building-a-dynamically-linked-application"> <h2 id="building-a-dynamically-linked-application">Building a dynamically linked application</h2> <p>Applications built with the glibc toolchain will by dynamically linked by default. Application that load shared libraries at runtime using <code>dlopen()</code> @@ -234,8 +229,7 @@ as that is currently the only toolchain that supports glibc and thus dynamic linking and loading. Take a look at the example Makefiles and the generated .nmf files for details on how to build dynamically linked applications. </aside> -</section><section id="generating-a-native-client-manifest-file-for-a-dynamically-linked-application"> -<span id="dynamic-loading-manifest"></span><h2 id="generating-a-native-client-manifest-file-for-a-dynamically-linked-application"><span id="dynamic-loading-manifest"></span>Generating a Native Client manifest file for a dynamically linked application</h2> +<h2 id="generating-a-native-client-manifest-file-for-a-dynamically-linked-application"><span id="dynamic-loading-manifest"></span>Generating a Native Client manifest file for a dynamically linked application</h2> <p>The Native Client manifest file specifies the name of the executable to run and must also specify any shared libraries that the application directly depends on. For indirect dependencies (such as libraries opened via @@ -312,7 +306,6 @@ intend to dlopen() at runtime you must explcitly list them in your call to </aside> <p>As an alternative to using <code>create_nmf</code>, it is possible to manually calculate the list of shared library dependencies using tools such as <code>objdump_</code>.</p> -</section><section id="deploying-a-dynamically-linked-application"> <h2 id="deploying-a-dynamically-linked-application">Deploying a dynamically linked application</h2> <p>As described above, an application’s manifest file must explicitly list all the executable code modules that the application directly depends on, including @@ -344,7 +337,6 @@ rename modules, it may be easier to re-run <code>create_nmf.py</code> to generat manifest file rather than edit the original manifest file. For hosted applications, you can check for name mismatches during testing by watching the request log of the web server hosting your test deployment.</p> -</section><section id="opening-a-shared-library-at-runtime"> <h2 id="opening-a-shared-library-at-runtime">Opening a shared library at runtime</h2> <p>Native Client supports a version of the POSIX standard <code>dlopen()</code> interface for opening libraries explicitly, after an application is already running. @@ -382,7 +374,6 @@ functions using <code>dlsym()</code>. When a user types in a query and clicks th button, the module calls <code>Magic8Ball()</code> to generate an answer, and returns the result to the user. Likewise when the user clicks the ‘Reverse’ button it calls the <code>Reverse()</code> function to reverse the string.</p> -</section><section id="troubleshooting"> <h2 id="troubleshooting">Troubleshooting</h2> <p>If your .nexe isn’t loading, the best place to look for information that can help you troubleshoot the JavaScript console and standard output from Chrome. @@ -419,6 +410,6 @@ expected library is missing.</dd> of command line flags when linking. Reconfigure your command line string to list libraries after the -o flag.</dd> </dl> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/devcycle/running.html b/native_client_sdk/doc_generated/devguide/devcycle/running.html index deafb2c150..a0af8715ce 100644 --- a/native_client_sdk/doc_generated/devguide/devcycle/running.html +++ b/native_client_sdk/doc_generated/devguide/devcycle/running.html @@ -25,14 +25,12 @@ <li><a class="reference internal" href="#technique-4-chrome-web-store-application-with-trusted-testers" id="id17">Technique 4: Chrome Web Store application with trusted testers</a></li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p>This document describes how to run Native Client applications during development.</p> <p>The workflow for PNaCl applications is straightfoward and will only be discussed briefly. For NaCl applications distributed through the web-store, there is a number of options and these will be discussed more in-depth.</p> -</section><section id="portable-native-client-pnacl-applications"> <h2 id="portable-native-client-pnacl-applications">Portable Native Client (PNaCl) applications</h2> <p>Running PNaCl applications from the open web is enabled in Chrome version 31 and above; therefore, no special provisions are required to run and test such @@ -43,7 +41,6 @@ JavaScript.</p> web server to serve the application’s files. The NaCl SDK comes with a simple local server built in, and the process of using it to run PNaCl applications is described in <a class="reference internal" href="/native-client/devguide/tutorial/tutorial-part1.html#tutorial-step-2"><em>the tutorial</em></a>.</p> -</section><section id="native-client-applications-and-the-chrome-web-store"> <h2 id="native-client-applications-and-the-chrome-web-store">Native Client applications and the Chrome Web Store</h2> <p>Before reading about how to run Native Client applications, it’s important to understand a little bit about how Native Client applications are distributed. @@ -136,9 +133,7 @@ running applications during development, and explain the three requirements listed in the table above (NaCl flag, web server, and CWS metadata). The subsequent sections of the document provide instructions for how to use each of the four techniques.</p> -</section><section id="prerequisites"> <h2 id="prerequisites">Prerequisites</h2> -<section id="browser-and-pepper-versions"> <h3 id="browser-and-pepper-versions">Browser and Pepper versions</h3> <p>Before you run a new build of your application, make sure that you’re using the correct version of Chrome. Each version of Chrome supports a corresponding @@ -148,16 +143,13 @@ application uses. For example, if you compiled your application using the <code>pepper_31</code> bundle, your application uses the Pepper 31 API, and you must run the application in Chrome 31 or higher. To check which version of Chrome you’re using, type <code>about:version</code> in the Chrome address bar.</p> -</section><section id="chrome-cache"> -<span id="cache"></span><h3 id="chrome-cache"><span id="cache"></span>Chrome Cache</h3> +<h3 id="chrome-cache"><span id="cache"></span>Chrome Cache</h3> <p>Chrome caches resources aggressively. You should disable Chrome’s cache whenever you are developing a Native Client application in order to make sure Chrome loads new versions of your application. Follow the instructions <a class="reference internal" href="/native-client/devguide/tutorial/tutorial-part1.html#tutorial-step-3"><em>in the tutorial</em></a>.</p> -</section></section><section id="requirements"> -<span id="id1"></span><h2 id="requirements"><span id="id1"></span>Requirements</h2> -<section id="native-client-flag"> -<span id="flag"></span><h3 id="native-client-flag"><span id="flag"></span>Native Client flag</h3> +<h2 id="requirements"><span id="id1"></span>Requirements</h2> +<h3 id="native-client-flag"><span id="flag"></span>Native Client flag</h3> <p>Native Client is automatically enabled for applications that are installed from the Chrome Web Store. To enable Native Client for applications that are not installed from the Chrome Web Store, you must explicitly turn on the Native @@ -184,8 +176,7 @@ outside the Chrome Web Store, you may need to enable the Native Client plugin:</ the Native Client plugin. You do not need to relaunch Chrome after enabling the Native Client plugin.</li> </ol> -</section><section id="web-server"> -<span id="id2"></span><h3 id="web-server"><span id="id2"></span>Web server</h3> +<h3 id="web-server"><span id="id2"></span>Web server</h3> <p>For security reasons, Native Client applications must come from a server (you can’t simply drag HTML files into your browser). The Native Client SDK comes with a lightweight Python web server that you can run to serve your application @@ -201,8 +192,7 @@ server. For example, to run the <code>flock</code> example in the SDK, start the and point your browser to <code>http://localhost:5103/demo/flock/</code>.</p> <p>Some of the applications need special flags to Chrome, and must be run with the <code>make run</code> command. See <a class="reference internal" href="/native-client/sdk/examples.html#id1"><em>Run the SDK examples</em></a> for more details.</p> -<section id="chrome-web-store-metadata"> -<span id="metadata"></span><h4 id="chrome-web-store-metadata"><span id="metadata"></span>Chrome Web Store metadata</h4> +<h4 id="chrome-web-store-metadata"><span id="metadata"></span>Chrome Web Store metadata</h4> <p>Applications published in the Chrome Web Store must be accompanied by CWS metadata; specifically, a Chrome Web Store manifest file named <code>manifest.json</code>, and at least one icon.</p> @@ -255,7 +245,6 @@ information about CWS manifest files and application icons, see:</p> <li><a class="reference external" href="/webstore/get_started_simple">Chrome Web Store Tutorial: Getting Started</a></li> <li><a class="reference external" href="/extensions/manifest">Chrome Web Store Formats: Manifest Files</a></li> </ul> -</section></section></section><section id="technique-1-local-server"> <h2 id="technique-1-local-server">Technique 1: Local server</h2> <p>To run your application from a local server:</p> <ul class="small-gap"> @@ -272,7 +261,6 @@ HTML file in Chrome, e.g.: server if you already have one running. You must still enable the Native Client flag in order to run your application from the server. </aside> -</section><section id="technique-2-packaged-application-loaded-as-an-unpacked-extension"> <h2 id="technique-2-packaged-application-loaded-as-an-unpacked-extension">Technique 2: Packaged application loaded as an unpacked extension</h2> <p>For development purposes, Chrome lets you load a packaged application as an unpacked extension. To load and run your packaged application as an unpacked @@ -308,7 +296,6 @@ Click the icon to launch the app.</li> application into Chrome (including troubleshooting information), see the <a class="reference external" href="/webstore/get_started_simple">Chrome Web Store Tutorial: Getting Started</a>.</p> <p>See also <a class="reference internal" href="/native-client/sdk/examples.html#run-sdk-examples-as-packaged"><em>Run the SDK examples as packaged apps</em></a>.</p> -</section><section id="technique-3-hosted-application-loaded-as-an-unpacked-extension"> <h2 id="technique-3-hosted-application-loaded-as-an-unpacked-extension">Technique 3: Hosted application loaded as an unpacked extension</h2> <p>For development purposes, Chrome lets you load a hosted application as an unpacked extension. To load and run your hosted application as an unpacked @@ -357,7 +344,6 @@ Click the icon to launch the app.</li> <p>For additional information about how to create CWS metadata and load your application into Chrome (including troubleshooting information), see the <a class="reference external" href="/webstore/get_started_simple">Chrome Web Store Tutorial: Getting Started</a>.</p> -</section><section id="technique-4-chrome-web-store-application-with-trusted-testers"> <h2 id="technique-4-chrome-web-store-application-with-trusted-testers">Technique 4: Chrome Web Store application with trusted testers</h2> <p>When you’re ready to test your application more broadly, you can upload the application to the Chrome Web Store and let some trusted testers run it. Here @@ -436,6 +422,6 @@ be able to find the application by searching in the CWS.</li> you must first unpublish the application. For additional information see <a class="reference external" href="/webstore/docs/publish">Publishing Your App</a>, and in particular <a class="reference external" href="/webstore/publish#testaccounts">Publishing to test accounts</a>.</p> -</section></section> +</section> {{/partials.standard_nacl_api}} diff --git a/native_client_sdk/doc_generated/devguide/devcycle/vs-addin.html b/native_client_sdk/doc_generated/devguide/devcycle/vs-addin.html index c6dfe08334..e77b0e2cf9 100644 --- a/native_client_sdk/doc_generated/devguide/devcycle/vs-addin.html +++ b/native_client_sdk/doc_generated/devguide/devcycle/vs-addin.html @@ -52,7 +52,6 @@ The Native Client add-in requires Visual Studio 2010 with Service Pack 1. No other versions of Visual Studio are currently supported. Visual Studio Express is also not supported. </aside> -<section id="introduction"> <h2 id="introduction">Introduction</h2> <p>The Native Client add-in for Visual Studio helps you develop your application more efficiently in many ways:</p> @@ -80,7 +79,6 @@ properties of your project so it can be built and run as either a Pepper plugin or a Native Client module. The platforms also define the behavior associated with the debug command so you can test your code while running in Visual Studio.</p> -</section><section id="platforms"> <h2 id="platforms">Platforms</h2> <p>It is helpful to consider the Visual Studio add-in platforms in two groups. One contains the PPAPI platform only. The other group, which we’ll call the Native @@ -97,7 +95,6 @@ your Native Client module, and also attaches an appropriate debugger.</p> code.</p> <p>When you run your project, Visual Studio launches the PPAPI and Native Client platforms in different ways, as explained in the next sections.</p> -<section id="the-ppapi-platform"> <h3 id="the-ppapi-platform">The PPAPI platform</h3> <p>The PPAPI platform builds your module as a dynamic library and launches a version of Chrome that’s configured to run the library as a plugin when it @@ -109,7 +106,6 @@ existing code incrementally, rewriting functions using the PPAPI interfaces one piece at a time. Since the module is built with Visual Studio’s native compiler (MSBuild) you can use the Visual Studio debugger to control and inspect your code.</p> -</section><section id="the-native-client-platforms"> <h3 id="the-native-client-platforms">The Native Client platforms</h3> <p>There are four Native Client platforms. All of them can be used to build Native Client modules. When you run one of the Native Client platforms Visual Studio @@ -118,7 +114,6 @@ builds the corresponding type of Native Client module (either a .nexe or fetches the module from the server and runs it. Visual Studio will also open a terminal window, launch an instance of nacl-gdb, and attach it to your module’s process so you can use gdb commands to debug.</p> -<section id="nacl32-and-nacl64"> <h4 id="nacl32-and-nacl64">NaCl32 and NaCl64</h4> <p>The platforms named NaCl32 and NaCl64 are targeted at x86 32-bit and 64-bit systems respectively. You need both platforms to build a full set of .nexe @@ -126,7 +121,6 @@ files when you are ready to distribute your application. Note, however, that when you are testing in Visual Studio you must select the NaCl64 platform (because Chrome for Windows runs Native Client in a 64-bit process). If you try to run from the NaCl32 platform you will get an error message.</p> -</section><section id="naclarm"> <h4 id="naclarm">NaClARM</h4> <p>The NaClARM platform is targeted at ARM-based processors. You can build .nexe files with the NaClARM platform in Visual Studio but you cannot run them from @@ -138,7 +132,6 @@ testing your module in Chrome.</p> <aside class="note"> Note: The NaClARM platform currently supports the newlib toolchain only. </aside> -</section><section id="pnacl"> <h4 id="pnacl">PNaCl</h4> <p>The PNaCl (portable NaCl) platform is included in the Visual Studio Native Client add-in versions 1.1 and higher. It supports the .pexe file format. A @@ -153,7 +146,6 @@ it as if you were working with a NaCl64 platform.</p> <aside class="note"> Note: The PNaCl platform currently supports the newlib toolchain only. </aside> -</section></section></section><section id="installing-the-add-in"> <h2 id="installing-the-add-in">Installing the add-in</h2> <p>In order to use the Native Client Visual Studio add-in, your development environment should include:</p> @@ -168,7 +160,6 @@ your regular version of Chrome.</li> bundle or greater. The version of Chrome that you use must be equal or greater than the version of the SDK bundle.</li> </ul> -<section id="set-environment-variables"> <h3 id="set-environment-variables">Set environment variables</h3> <p>Before you run the installer you must define two Windows environment variables. They point to the bundle in the Native Client SDK that you use to build your @@ -200,7 +191,6 @@ SxS\Application\chrome.exe</code></td> </tr> </tbody> </table> -</section><section id="download-the-add-in"> <h3 id="download-the-add-in">Download the add-in</h3> <p>The Native Client Visual Studio add-in is a separate bundle in the SDK named <code>vs_addin</code>. Open a command prompt window, go to the top-level SDK directory, @@ -214,7 +204,6 @@ installer files, and a directory of examples.</p> Note: The vs_addin bundle is only visible when you run <code>naclsdk</code> on a Windows system. </aside> -</section><section id="run-the-installer"> <h3 id="run-the-installer">Run the installer</h3> <p>The installer script is located inside the <code>vs_addin</code> folder in the SDK. Right click on the file <code>install.bat</code> and run it as administrator.</p> @@ -245,12 +234,10 @@ administrator.</p> selecting Add-in Manager in the Visual Studio Tools menu. If the add-in has been installed it will appear in the list of available add-ins. Select it and read its description.</p> -</section></section><section id="try-the-hello-world-gles-sample-project"> <h2 id="try-the-hello-world-gles-sample-project">Try the <code>hello_world_gles</code> sample project</h2> <p>The add-in comes with an examples directory. Open the sample project <code>examples\hello_world_gles\hello_world_gles.sln</code>. This project is an application that displays a spinning cube.</p> -<section id="select-the-nacl64-platform"> <h3 id="select-the-nacl64-platform">Select the NaCl64 platform</h3> <p>Open the sample project in Visual Studio, select the <code>Configuration Manager</code>, and confirm that the active solution configuration is <code>Debug</code> and the active @@ -259,7 +246,6 @@ project platform is <code>NaCl64</code>. Note that the platform for the <code>Configuration Manager</code> from the <code>Build</code> menu or the project’s <code>Properties</code> window.)</p> <img alt="/native-client/images/visualstudio1.png" src="/native-client/images/visualstudio1.png" /> -</section><section id="build-and-run-the-project"> <h3 id="build-and-run-the-project">Build and run the project</h3> <p>Use the debugging command (F5) to build and run the project. As the wheels start to turn, you may be presented with one or more alerts. They are benign; @@ -287,7 +273,6 @@ Stop the debugging session by closing the Chrome window, or select the stop debugging command from the debug menu. The nacl-gdb window will close when you stop running the program.</li> </ol> -</section><section id="test-the-nacl-gdb-debugger"> <h3 id="test-the-nacl-gdb-debugger">Test the nacl-gdb debugger</h3> <p>Add a breakpoint at the SwapBuffers call in the function MainLoop, which is in hello_world.cc.</p> @@ -297,25 +282,21 @@ nacl-gcb and the program will pause there. Type c to continue running. You can use gdb commands to set more breakpoints and step through the application. For details, see <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html#using-gdb"><em>Debugging with nacl-gdb</em></a> (scroll down to the end of the section to see some commonly used gdb commands).</p> -</section><section id="test-the-visual-studio-debugger"> <h3 id="test-the-visual-studio-debugger">Test the Visual Studio debugger</h3> <p>If you’ve installed the <code>PPAPI</code> platform, go back to the <code>Configuration Manager</code> and select the <code>PPAPI</code> platform. This time when Chrome launches the <code>nacl-gdb</code> window will not appear; the Visual Studio debugger is fully engaged and on the job.</p> -</section><section id="inspect-the-platform-properties"> <h3 id="inspect-the-platform-properties">Inspect the platform properties</h3> <p>At this point, it may be helpful to take a look at the properties that are associated with the PPAPI and Native Client platforms—see the settings in the sample project as an example.</p> -</section></section><section id="developing-for-native-client-in-visual-studio"> <h2 id="developing-for-native-client-in-visual-studio">Developing for Native Client in Visual Studio</h2> <p>After you’ve installed the add-in and tried the sample project, you’re ready to start working with your own code. You can reuse the sample project and the PPAPI and Native Client platforms it already has by replacing the source code with your own. More likely, you will add the platforms to an existing project, or to a new project that you create from scratch.</p> -<section id="adding-platforms-to-a-project"> <h3 id="adding-platforms-to-a-project">Adding platforms to a project</h3> <p>Follow these steps to add the Native Client and PPAPI platforms to a project:</p> <ol class="arabic simple"> @@ -345,7 +326,6 @@ Configuration type is correct:<ul class="small-gap"> </ul> </li> </ol> -</section><section id="selecting-a-toolchain"> <h3 id="selecting-a-toolchain">Selecting a toolchain</h3> <p>When you build a Native Client module directly from the SDK you can use two different toolchains, newlib or glibc. See <a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html"><em>Dynamic Linking and Loading @@ -359,7 +339,6 @@ Currently, the NaClARM and PNaCl platforms only support the newlib toolchain. </aside> <p>There is no toolchain property for the PPAPI platform. The PPAPI platform uses the toolchain and libraries that come with Visual Studio.</p> -</section><section id="adding-libraries-to-a-project"> <h3 id="adding-libraries-to-a-project">Adding libraries to a project</h3> <p>If your Native Client application requires libraries that are not included in the SDK you must add them to the project properties (under <code>Configuration @@ -368,11 +347,9 @@ Visual Studio project. This list of dependencies is a semi-colon delimited list. On the PPAPI platform the library names include the .lib extension (e.g., <code>ppapi_cpp.lib;ppapi.lib</code>). On the Native Client platforms the extension is excluded (e.g., <code>ppapi_cpp;ppapi</code>).</p> -</section><section id="running-a-web-server"> <h3 id="running-a-web-server">Running a web server</h3> <p>In order for the Visual Studio add-in to test your Native Client module, you must serve the module from a web server. There are two options:</p> -<section id="running-your-own-server"> <h4 id="running-your-own-server">Running your own server</h4> <p>When you start a debug run Visual Studio launches Chrome and tries to connect to the web server at the address found in the Chrome command arguments (see the @@ -382,7 +359,6 @@ specify its address in the command arguments property, and confirm that your server is running before starting a debug session. Also be certain that the server has all the files it needs to deliver a Native Client module (see “Keeping track of all the pieces”, below).</p> -</section><section id="running-the-sdk-server"> <h4 id="running-the-sdk-server">Running the SDK server</h4> <p>If there is no web server running at the specified port, Visual Studio will try to launch the simple Python web server that comes with the Native Client SDK. @@ -392,7 +368,6 @@ It looks for a copy of the server in the SDK itself (at Visual Studio launches the server. The server output appears in Visual Studio’s Output window, in the pane named “Native Client Web Server Output”. A server launched in this way is terminated when the debugging session ends.</p> -</section></section><section id="keeping-track-of-all-the-pieces"> <h3 id="keeping-track-of-all-the-pieces">Keeping track of all the pieces</h3> <p>No matter where the web server lives or how it’s launched you must make sure that it has all the files that your application needs:</p> @@ -433,7 +408,6 @@ contains html files built with both toolchains (<code>index_glibc.html</code> an <code>index_newlib.html</code>). The .nexe and .nmf files are found in the newlib and glibc subfolders. For additional information about the parts of a Native Client application, see <a class="reference internal" href="/native-client/devguide/coding/application-structure.html"><em>Application Structure</em></a>.</p> -</section><section id="using-the-debuggers"> <h3 id="using-the-debuggers">Using the debuggers</h3> <p>PPAPI plugins are built natively by Visual Studio’s compiler (MSBuild), and work with Visual Studio’s debugger in the usual way. You can set breakpoints in @@ -464,12 +438,10 @@ debugger to attach. If you use the Start Without Debugging command, no debugger attaches and Chrome just waits patiently. To use Start Without Debugging, switch to the Release configuration, or manually remove the offending argument from the <code>Command Arguments</code> property.</p> -</section><section id="disable-chrome-caching"> <h3 id="disable-chrome-caching">Disable Chrome caching</h3> <p>When you debug with a Native Client platform you might want to <a class="reference internal" href="/native-client/devguide/devcycle/running.html#cache"><em>disable Chrome’s cache</em></a> to be sure you are testing your latest and greatest code.</p> -</section><section id="a-warning-about-postmessage"> <h3 id="a-warning-about-postmessage">A warning about PostMessage</h3> <p>Some Windows libraries define the symbol <code>PostMessage</code> as <code>PostMessageW</code>. This can cause havoc if you are working with the PPAPI platform and you use the @@ -482,7 +454,6 @@ testing on the PPAPI platform. Here it is:</p> #undef PostMessage #endif </pre> -</section><section id="porting-windows-applications-to-native-client-in-visual-studio"> <h3 id="porting-windows-applications-to-native-client-in-visual-studio">Porting Windows applications to Native Client in Visual Studio</h3> <p>At Google I/O 2012 we demonstrated how to port a Windows desktop application to Native Client in 60 minutes. The <a class="reference external" href="http://www.youtube.com/watch?v=1zvhs5FR0X8&feature=plcp">video</a> is available to @@ -503,13 +474,11 @@ can run in either the <code>PPAPI</code> or the <code>NaCl64</code> platform.</p progressively defining the symbols STEP1 through STEP6 in the source. Inline comments explain how each successive step changes the code. View the example code to see how it’s actually done. Here is a summary of the process:</p> -<section id="win32-platform"> <h4 id="win32-platform">Win32 Platform</h4> <dl class="docutils"> <dt>STEP1 Run the desktop application</dt> <dd>Begin by running the original Windows application in the Win32 platform.</dd> </dl> -</section><section id="ppapi-platform"> <h4 id="ppapi-platform">PPAPI Platform</h4> <dl class="docutils"> <dt>STEP2 Launch Chrome with an empty Native Client module</dt> @@ -536,13 +505,12 @@ porting pieces of the application one feature at a time.</dd> <dd>All the Windows code is def’d out, proving we are PPAPI-compliant. The functional code that is running is the same as STEP5.</dd> </dl> -</section><section id="nacl64-platform"> <h4 id="nacl64-platform">NaCl64 Platform</h4> <dl class="docutils"> <dt>Run the Native Client Module in the NaCl64 platform</dt> <dd>You are still running the STEP6 code, but as a Native Client module rather than a Pepper plugin.</dd> </dl> -</section></section></section></section> +</section> {{/partials.standard_nacl_api}} diff --git a/native_client_sdk/doc_generated/devguide/distributing.html b/native_client_sdk/doc_generated/devguide/distributing.html index 16ae732df3..4b4dcf70b5 100644 --- a/native_client_sdk/doc_generated/devguide/distributing.html +++ b/native_client_sdk/doc_generated/devguide/distributing.html @@ -18,7 +18,6 @@ </div><p>This document describes how to distribute Portable Native Client applications on the web, and Native Client applications through the <a class="reference external" href="/webstore">Chrome Web Store</a> (CWS).</p> -<section id="portable-native-client"> <h2 id="portable-native-client">Portable Native Client</h2> <p>Portable Native Client is enabled by default for web pages, so no separate distribution step is requred. Making PNaCl a part of your web application is as @@ -30,7 +29,6 @@ abiding by the <a class="reference external" href="http://en.wikipedia.org/wiki/ <strong>pexe</strong> must either be served from the same domain with the HTML, or the <a class="reference external" href="http://en.wikipedia.org/wiki/Cross-origin_resource_sharing">CORS mechanism</a> should be used to safely host them on a different domain.</p> -</section><section id="non-portable-native-client"> <h2 id="non-portable-native-client">Non-portable Native Client</h2> <p>NaCl modules are only allowed for applications distributed through the <a class="reference external" href="https://chrome.google.com/webstore/category/apps">Chrome Web Store (CWS)</a> @@ -49,15 +47,13 @@ well. Here are a few pointers to relevant documentation:</p> </ul> <p>In this document, we’ll focus only on distribution issues specific to applications that contain NaCl modules.</p> -<section id="packaged-application"> -<span id="distributing-packaged"></span><h3 id="packaged-application"><span id="distributing-packaged"></span>Packaged application</h3> +<h3 id="packaged-application"><span id="distributing-packaged"></span>Packaged application</h3> <p>A packaged application is a special zip file (with a .crx extension) hosted in the Chrome Web Store. This file contains all of the application parts: A Chrome Web Store manifest file (manifest.json), an icon, and all of the regular Native Client application files. Refer to <a class="reference external" href="/apps/about_apps">Packaged Apps</a> for more information about creating a packaged application.</p> -<section id="reducing-the-size-of-the-user-download-package"> <h4 id="reducing-the-size-of-the-user-download-package">Reducing the size of the user download package</h4> <aside class="note"> <strong>Tip:</strong> @@ -236,8 +232,7 @@ function getPath(name) { <li><p class="first">Test your app, create a zip file, and upload the app to the CWS as before.</p> </li> </ol> -</section><section id="additional-considerations-for-a-packaged-application"> -<span id="additional-considerations-packaged"></span><h4 id="additional-considerations-for-a-packaged-application"><span id="additional-considerations-packaged"></span>Additional considerations for a packaged application</h4> +<h4 id="additional-considerations-for-a-packaged-application"><span id="additional-considerations-packaged"></span>Additional considerations for a packaged application</h4> <ul class="small-gap"> <li>In the description of your application in the CWS, make sure to mention that your application is a Native Client application that only works with the @@ -262,18 +257,15 @@ uses the HTML5 File API.</li> <li>You can place your application in the Google Web Store with access only to certain people for testing. See <a class="reference external" href="/webstore/publish">Publishing to test accounts</a> for more information.</li> </ul> -</section></section><section id="extension"> <h3 id="extension">Extension</h3> <p>The NaCl-specific notes for a <a class="reference internal" href="#distributing-packaged"><em>package application</em></a> apply to extensions as well.</p> -</section><section id="hosted-application"> <h3 id="hosted-application">Hosted application</h3> <p>The .html file, .nmf file (Native Client manifest file), and .nexe files must be served from the same domain, and the Chrome Web Store manifest file must specify the correct, verified domain. Other files can be served from the same or another domain.</p> <p>In addition, see <a class="reference internal" href="#additional-considerations-packaged"><em>Additional considerations for a packaged application</em></a>.</p> -</section><section id="registering-native-client-modules-to-handle-mime-types"> <h3 id="registering-native-client-modules-to-handle-mime-types">Registering Native Client modules to handle MIME types</h3> <p>If you want Chrome to use a Native Client module to display a particular type of content, you can associate the MIME type of that content with the Native @@ -322,6 +314,6 @@ example shows an extension with two .nmf files that handle three MIME types.</p> <p>The <code>nacl_modules</code> attribute is optional—specify this attribute only if you want Chrome to use a Native Client module to display a particular type of content.</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part1.html b/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part1.html index 6b3227e712..8664bb8af3 100644 --- a/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part1.html +++ b/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part1.html @@ -22,14 +22,12 @@ <li><a class="reference internal" href="#next-steps" id="id13">Next steps</a></li> </ul> -</div><section id="overview"> -<h2 id="overview">Overview</h2> +</div><h2 id="overview">Overview</h2> <p>This tutorial shows how to build and run a web application using Portable Native Client (PNaCl). This is a client-side application that uses HTML, JavaScript and a Native Client module written in C++. The PNaCl toolchain is used to enable running the Native Client module directly from a web page.</p> <p>It’s recommended to read the <a class="reference internal" href="/native-client/overview.html"><em>Native Client Technical Overview</em></a> prior to going through this tutorial.</p> -<section id="what-the-application-in-this-tutorial-does"> <h3 id="what-the-application-in-this-tutorial-does">What the application in this tutorial does</h3> <p>The application in this tutorial shows how to load a Native Client module in a web page, and how to send messages between JavaScript and the C++ code in the @@ -39,7 +37,6 @@ Client module receives a message, it checks whether the message is equal to the string <code>'hello'</code>. If it is, the Native Client module returns a message saying <code>'hello from NaCl'</code>. A JavaScript alert panel displays the message received from the Native Client module.</p> -</section><section id="communication-between-javascript-and-native-client-modules"> <h3 id="communication-between-javascript-and-native-client-modules">Communication between JavaScript and Native Client modules</h3> <p>The Native Client programming model supports bidirectional communication between JavaScript and the Native Client module (C/C++ code). Both sides can initiate @@ -52,12 +49,10 @@ system is part of the Pepper API, and is described in detail in <a class="reference internal" href="/native-client/devguide/coding/message-system.html"><em>Developer’s Guide: Messaging System</em></a>. It is also similar to the way <a class="reference external" href="http://en.wikipedia.org/wiki/Web_worker">web workers</a> interact with the main document in JavaScript.</p> -</section></section><section id="step-1-download-and-install-the-native-client-sdk"> <h2 id="step-1-download-and-install-the-native-client-sdk">Step 1: Download and install the Native Client SDK</h2> <p>Follow the instructions on the <a class="reference internal" href="/native-client/sdk/download.html"><em>Download</em></a> page to download and install the Native Client SDK.</p> -</section><section id="step-2-start-a-local-server"> -<span id="tutorial-step-2"></span><h2 id="step-2-start-a-local-server"><span id="tutorial-step-2"></span>Step 2: Start a local server</h2> +<h2 id="step-2-start-a-local-server"><span id="tutorial-step-2"></span>Step 2: Start a local server</h2> <p>To simulate a production environment, the SDK provides a simple web server that can be used to serve the application on <code>localhost</code>. A convenience Makefile rule called <code>serve</code> is the easiest way to invoke it:</p> @@ -77,8 +72,7 @@ Client SDK</em></a> for more details. accessed at <code>http://localhost:5103</code>.</p> <p>Any server can be used for the purpose of development. The one provided with the SDK is just a convenience, not a requirement.</p> -</section><section id="step-3-set-up-the-chrome-browser"> -<span id="tutorial-step-3"></span><h2 id="step-3-set-up-the-chrome-browser"><span id="tutorial-step-3"></span>Step 3: Set up the Chrome browser</h2> +<h2 id="step-3-set-up-the-chrome-browser"><span id="tutorial-step-3"></span>Step 3: Set up the Chrome browser</h2> <p>PNaCl is enabled by default in Chrome version 31 and later. Please make sure that you have a suitable version to work through this tutorial. It’s also important to use a Chrome version that’s the same or newer than the SDK bundle @@ -100,7 +94,6 @@ DevTools is open)”.</li> <li>Keep the Developer Tools pane open while developing Native Client applications.</li> </ul> -</section><section id="step-4-stub-code-for-the-tutorial"> <h2 id="step-4-stub-code-for-the-tutorial">Step 4: Stub code for the tutorial</h2> <p>The stub code for the tutorial is avalable in the SDK, in <code>pepper_$(VERSION)/getting_started/part1</code>. It contains the following files:</p> @@ -124,8 +117,7 @@ on the structure of a typical Native Client application, see <p>The stub code is intentionally very minimal. The C++ code does not do anything except correctly initialize itself. The JavaScript code waits for the Native Client module to load and changes the status text on the web page accordingly.</p> -</section><section id="step-5-compile-the-native-client-module-and-run-the-stub-application"> -<span id="tutorial-step-5"></span><h2 id="step-5-compile-the-native-client-module-and-run-the-stub-application"><span id="tutorial-step-5"></span>Step 5: Compile the Native Client module and run the stub application</h2> +<h2 id="step-5-compile-the-native-client-module-and-run-the-stub-application"><span id="tutorial-step-5"></span>Step 5: Compile the Native Client module and run the stub application</h2> <p>To compile the Native Client module, run <code>make</code>:</p> <pre> $ cd pepper_$(VERSION)/getting_started/part1 @@ -141,7 +133,6 @@ Modules</em></a> for more details.</p> to <code>http://localhost:5103/part1</code>. Chrome should load the Native Client module successfully and the Status text should change from “LOADING...” to “SUCCESS”. If you run into problems, check out the <a class="reference internal" href="#tutorial-troubleshooting"><em>Troubleshooting section</em></a> below.</p> -</section><section id="step-6-modify-the-javascript-code-to-send-a-message-to-the-native-client-module"> <h2 id="step-6-modify-the-javascript-code-to-send-a-message-to-the-native-client-module">Step 6: Modify the JavaScript code to send a message to the Native Client module</h2> <p>In this step, you’ll modify the web page (<code>index.html</code>) to send a message to the Native Client module after the page loads the module.</p> @@ -155,7 +146,6 @@ function moduleDidLoad() { HelloTutorialModule.postMessage('hello'); } </pre> -</section><section id="step-7-implement-a-message-handler-in-the-native-client-module"> <h2 id="step-7-implement-a-message-handler-in-the-native-client-module">Step 7: Implement a message handler in the Native Client module</h2> <p>In this step, you’ll modify the Native Client module (<code>hello_tutorial.cc</code>) to respond to the message received from the JavaScript code in the application. @@ -200,14 +190,12 @@ virtual void HandleMessage(const pp::Var& var_message) { <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_instance.html#a5dce8c8b36b1df7cfcc12e42397a35e8">pp::Instance.HandleMessage</a> and <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_instance.html#a67e888a4e4e23effe7a09625e73ecae9">pp::Instance.PostMessage</a> member functions.</p> -</section><section id="step-8-compile-the-native-client-module-and-run-the-application-again"> <h2 id="step-8-compile-the-native-client-module-and-run-the-application-again">Step 8: Compile the Native Client module and run the application again</h2> <p>Compile the Native Client module by running the <code>make</code> command again.</p> <p>Re-run the application by reloading <code>http://localhost:5103/part1</code> in Chrome.</p> <p>After Chrome loads the Native Client module, you should see an alert panel appear with the message sent from the module.</p> -</section><section id="troubleshooting"> -<span id="tutorial-troubleshooting"></span><h2 id="troubleshooting"><span id="tutorial-troubleshooting"></span>Troubleshooting</h2> +<h2 id="troubleshooting"><span id="tutorial-troubleshooting"></span>Troubleshooting</h2> <p>If your application doesn’t run, see <a class="reference internal" href="#tutorial-step-3"><em>Step 3</em></a> above to verify that you’ve set up your environment correctly, including both the Chrome browser and the local server. Make sure that you’re running a correct version of @@ -223,7 +211,6 @@ possibility that the Native Client module has a bug; <a class="reference interna <li>The <a class="reference internal" href="/native-client/devguide/coding/progress-events.html"><em>Progress Events</em></a> document contains some useful information about handling error events.</li> </ul> -</section><section id="next-steps"> <h2 id="next-steps">Next steps</h2> <ul class="small-gap"> <li>See the <a class="reference internal" href="/native-client/devguide/coding/application-structure.html"><em>Application Structure</em></a> @@ -241,6 +228,6 @@ what libraries have been ported for use with Native Client. If you port an open-source library for your own use, we recommend adding it to naclports (see <a class="reference external" href="http://code.google.com/p/naclports/wiki/HowTo_Checkin">How to check code into naclports</a>).</li> </ul> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html b/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html index 7731fccd7e..72c33bed0c 100644 --- a/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html +++ b/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html @@ -28,8 +28,7 @@ <li><a class="reference internal" href="#example-specific-behavior-with-example-js" id="id13">Example-specific behavior with example.js</a></li> </ul> -</div><section id="overview"> -<h2 id="overview">Overview</h2> +</div><h2 id="overview">Overview</h2> <p>This tutorial shows how to convert the finished PNaCl web application from <a class="reference internal" href="/native-client/devguide/tutorial/tutorial-part1.html"><em>Part 1</em></a> to use the Native Client SDK build system and common JavaScript files. It also demonstrates some techniques to make your web @@ -42,13 +41,11 @@ your application.</p> <p>The finished code for this example can be found in the <code>pepper_$(VERSION)/getting_started/part2</code> directory in the Native Client SDK download.</p> -</section><section id="using-the-native-client-sdk-build-system"> <h2 id="using-the-native-client-sdk-build-system">Using the Native Client SDK build system</h2> <p>This section describes how to use the SDK build system. To do so, we’ll make changes in the makefile. Because the makefile in part1 and part2 are so different, it is easier to start from scratch. Here is the contents of the new makefile. The following sections will describe it in more detail.</p> -<section id="simplifying-the-makefile"> <h3 id="simplifying-the-makefile">Simplifying the Makefile</h3> <p>The makefile from part1 only supports one toolchain (PNaCl) and one configuration (Release). It also only supports one source file. It’s relatively @@ -85,7 +82,6 @@ endif $(eval $(call NMF_RULE,$(TARGET),)) </pre> -</section><section id="choosing-valid-toolchains-and-including-common-mk"> <h3 id="choosing-valid-toolchains-and-including-common-mk">Choosing valid toolchains, and including common.mk</h3> <p>The makefile begins by specifying the toolchains that are valid for this project. The Native Client SDK build system supports multi-toolchain projects @@ -116,7 +112,6 @@ to compile and link a project, which we’ll use below.</p> <pre class="prettyprint"> include $(NACL_SDK_ROOT)/tools/common.mk </pre> -</section><section id="configuring-your-project"> <h3 id="configuring-your-project">Configuring your project</h3> <p>After including <code>tools/common.mk</code>, we configure the project by specifying its name, the sources and libraries it uses:</p> @@ -161,7 +156,6 @@ SOURCES = foo.cc \ baz.cc \ quux.cc </pre> -</section><section id="build-macros"> <h3 id="build-macros">Build macros</h3> <p>For many projects, the following build macros do not need to be changed; they will use the variables we’ve defined above.</p> @@ -205,12 +199,10 @@ each executable generated in the previous step:</p> <pre class="prettyprint"> $(eval $(call NMF_RULE,$(TARGET),)) </pre> -</section></section><section id="making-index-html-work-for-chrome-apps"> <h2 id="making-index-html-work-for-chrome-apps">Making index.html work for Chrome Apps</h2> <p>This section describes the changes necessary to make the HTML and JavaScript in part1 CSP-compliant. This is required if you want to build a <a class="reference external" href="/apps/about_apps">Chrome App</a>, but is not necessary if you want to use PNaCl on the open web.</p> -<section id="csp-rules"> <h3 id="csp-rules">CSP rules</h3> <p><a class="reference external" href="/apps/contentSecurityPolicy#what">Chrome Apps CSP</a> restricts you from doing the following:</p> @@ -223,7 +215,6 @@ iframe.</li> <li>You can’t use string-to-JavaScript methods like <code>eval()</code> and <code>new Function()</code>.</li> </ul> -</section><section id="making-index-html-csp-compliant"> <h3 id="making-index-html-csp-compliant">Making index.html CSP-compliant</h3> <p>To make our application CSP-compliant, we have to remove inline scripting. As described above, we can’t use inline <code><script></code> blocks or event handlers. This @@ -245,7 +236,6 @@ this example.</p> ... </pre> <p>This logic is now handled by <code>common.js</code>.</p> -</section><section id="making-index-html-support-different-toolchains-and-configurations"> <h3 id="making-index-html-support-different-toolchains-and-configurations">Making index.html support different toolchains and configurations</h3> <p>Finally, there are a few changes to <code>index.html</code> that are not necessary for CSP-compliance, but help make the SDK examples more generic.</p> @@ -275,14 +265,12 @@ here the common.js module creates a new <embed> element and adds it to the --> <div id="listener"></div> </pre> -</section></section><section id="sharing-common-code-with-common-js"> <h2 id="sharing-common-code-with-common-js">Sharing common code with common.js</h2> <p><code>common.js</code> contains JavaScript code that each example uses to create a NaCl module, handle messages from that module and other common tasks like displaying the module load status and logging messages. Explaining all of <code>common.js</code> is outside the scope of this document, but please look at the documentation in that file for more information.</p> -<section id="loading-the-page-and-creating-the-module"> <h3 id="loading-the-page-and-creating-the-module">Loading the page and creating the module</h3> <p>Since we’ve added <code><script></code> tags for <code>common.js</code> and <code>example.js</code> to the <code>head</code> element, they will be loaded and executed before the rest of the @@ -409,7 +397,6 @@ function moduleDidLoad() { } } </pre> -</section></section><section id="example-specific-behavior-with-example-js"> <h2 id="example-specific-behavior-with-example-js">Example-specific behavior with example.js</h2> <p>As described in the previous section, <code>common.js</code> will call certain functions during the module loading process. This example only needs to respond to two: @@ -436,6 +423,6 @@ function handleMessage(message) { logEl.textContent += message.data; } </pre> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/faq.html b/native_client_sdk/doc_generated/faq.html index 80835aa33d..f2fafbbf1c 100644 --- a/native_client_sdk/doc_generated/faq.html +++ b/native_client_sdk/doc_generated/faq.html @@ -79,9 +79,7 @@ Client (NaCl) and Portable Native Client (PNaCl, pronounced <li>Scan through the <a class="reference internal" href="/native-client/sdk/release-notes.html"><em>Release Notes</em></a>.</li> <li>Search through or ask on the <a class="reference internal" href="/native-client/help.html"><em>Native Client Forums</em></a>.</li> </ul> -<section id="what-is-native-client-good-for"> <h2 id="what-is-native-client-good-for">What is Native Client Good For?</h2> -<section id="why-did-google-build-native-client"> <h3 id="why-did-google-build-native-client">Why did Google build Native Client?</h3> <ul class="small-gap"> <li><strong>Performance:</strong> Native Client modules run nearly as fast as native @@ -125,12 +123,10 @@ gains support for new processors and fully uses their capabilities.</li> </ul> <p>For more details, refer to the <a class="reference internal" href="/native-client/nacl-and-pnacl.html"><em>history behind and comparison of NaCl and PNaCl</em></a>.</p> -</section><section id="when-should-i-use-portable-native-client-instead-of-native-client"> <h3 id="when-should-i-use-portable-native-client-instead-of-native-client">When should I use Portable Native Client instead of Native Client?</h3> <p>See <a class="reference internal" href="/native-client/nacl-and-pnacl.html"><em>NaCl and PNaCl</em></a>. In short: PNaCl works on the Open Web platform delivered by Chrome whereas NaCl only works on the Chrome Web Store.</p> -</section><section id="when-should-i-use-portable-native-client-native-client"> <h3 id="when-should-i-use-portable-native-client-native-client">When should I use Portable Native Client / Native Client?</h3> <p>The following are some typical use cases. For details, see the <a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a>.</p> @@ -149,7 +145,6 @@ system for a game).</li> </ul> <p>Portable Native Client and Native Client are versatile technologies which are used in many other contexts outside of Chrome.</p> -</section><section id="how-fast-does-code-run-in-portable-native-client"> <h3 id="how-fast-does-code-run-in-portable-native-client">How fast does code run in Portable Native Client?</h3> <p>Fast! The SPEC2k benchmarks (C, C++ and floating-point benchmarks) give the following overhead for optimized PNaCl compared to regular optimized @@ -184,7 +179,6 @@ native code such as <a class="reference internal" href="/native-client/reference </ul> <p>If your code isn’t performing as close to native speed as you’d expect, <a class="reference internal" href="/native-client/help.html"><em>let us know</em></a>!</p> -</section><section id="why-use-portable-native-client-instead-of-technology-x"> <h3 id="why-use-portable-native-client-instead-of-technology-x">Why use Portable Native Client instead of <em><technology X></em>?</h3> <p>Many other technologies can be compared to Portable Native Client: Flash, Java, Silverlight, ActiveX, .NET, asm.js, etc...</p> @@ -195,14 +189,11 @@ other technologies.</p> <p>Portable Native Client complement other technologies by giving web developers a new capability: the ability to run fast, secure native code from a web browser in an architecture-independent way.</p> -</section><section id="if-i-want-direct-access-to-the-os-should-i-use-native-client"> <h3 id="if-i-want-direct-access-to-the-os-should-i-use-native-client">If I want direct access to the OS, should I use Native Client?</h3> <p>No—Native Client does not provide direct access to the OS or devices, or otherwise bypass the JavaScript security model. For more information, see later sections of this FAQ.</p> -</section></section><section id="development-environments-and-tools"> <h2 id="development-environments-and-tools">Development Environments and Tools</h2> -<section id="what-development-environment-and-development-operating-system-do-you-recommend"> <h3 id="what-development-environment-and-development-operating-system-do-you-recommend">What development environment and development operating system do you recommend?</h3> <p>You can develop on Windows, Mac, or Linux, and the resulting Native Client or Portable Native Client application will run inside the Google Chrome browser on @@ -212,7 +203,6 @@ and we’re working on self-hosting a full development environment on Portab Native Client.</p> <p>Any editor+shell combination should work as well as IDEs like Eclipse, Visual Studio with the <a class="reference internal" href="/native-client/devguide/devcycle/vs-addin.html"><em>Native Client Add-In</em></a> on Windows, or Xcode on Mac OSX.</p> -</section><section id="i-m-not-familiar-with-native-development-tools-can-i-still-use-the-native-client-sdk"> <h3 id="i-m-not-familiar-with-native-development-tools-can-i-still-use-the-native-client-sdk">I’m not familiar with native development tools, can I still use the Native Client SDK?</h3> <p>You may find our <a class="reference internal" href="/native-client/devguide/tutorial/index.html"><em>Tutorial</em></a> and <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building instructions</em></a> useful, and you can look at @@ -221,9 +211,7 @@ examples are built and run.</p> <p>You’ll need to learn how to use some tools (like GCC, LLVM, make, Eclipse, Visual Studio, or Xcode) before you can get very far with the SDK. Try seaching for an <a class="reference external" href="https://www.google.com/search?q=gcc+introduction">introduction to GCC</a>.</p> -</section></section><section id="openness-and-supported-architectures-and-languages"> <h2 id="openness-and-supported-architectures-and-languages">Openness, and Supported Architectures and Languages</h2> -<section id="is-native-client-open-is-it-a-standard"> <h3 id="is-native-client-open-is-it-a-standard">Is Native Client open? Is it a standard?</h3> <p>Native Client is completely open: the executable format is open and the <a class="reference external" href="https://code.google.com/p/nativeclient/">source code is open</a>. Right @@ -232,7 +220,6 @@ to consider Native Client for standardization.</p> <p>We consistenly try to document our design and implementation and hope to standardize Portable Native Client when it gains more traction. A good example is our <a class="reference internal" href="/native-client/reference/pnacl-bitcode-abi.html"><em>PNaCl bitcode reference manual</em></a>.</p> -</section><section id="what-are-the-supported-instruction-set-architectures"> <h3 id="what-are-the-supported-instruction-set-architectures">What are the supported instruction set architectures?</h3> <p>Portable Native Client uses an architecture-independent format (the <code>.pexe</code>) which can currently be translated to execute on processors @@ -249,8 +236,7 @@ deem them better suited to a web store than to the open web.</p> portability to JavaScript and can adapt to new instruction set architectures without requiring recompilation. The web is better when it’s platform-independent, and we’d like it to stay that way.</p> -</section><section id="do-i-have-to-use-c-or-c-i-d-really-like-to-use-another-language"> -<span id="other-languages"></span><h3 id="do-i-have-to-use-c-or-c-i-d-really-like-to-use-another-language"><span id="other-languages"></span>Do I have to use C or C++? I’d really like to use another language.</h3> +<h3 id="do-i-have-to-use-c-or-c-i-d-really-like-to-use-another-language"><span id="other-languages"></span>Do I have to use C or C++? I’d really like to use another language.</h3> <p>Right now only C and C++ are supported directly by the toolchain in the SDK. C# and other languages in the .NET family are supported via the <a class="reference external" href="https://github.com/elijahtaylor/mono">Mono port</a> for Native Client. Moreover, there are several ongoing projects to support @@ -260,7 +246,6 @@ as well as to compile more languages to LLVM’s intermediate representation transpile languages to C/C++ (source-to-source compilation).</p> <p>If you’re interested in getting other languages working, please contact the Native Client team by way of the <a class="reference external" href="https://groups.google.com/group/native-client-discuss">native-client-discuss</a> mailing list.</p> -</section><section id="do-you-only-support-chrome-what-about-other-browsers"> <h3 id="do-you-only-support-chrome-what-about-other-browsers">Do you only support Chrome? What about other browsers?</h3> <p>We aim to support multiple browsers. However, a number of features that we consider requirements for a production-quality system that keeps the @@ -269,23 +254,19 @@ browser. Specific examples are an out-of-process plugin architecture and appropriate interfaces for integrated 3D graphics. We have worked closely with Chromium developers to deliver these features and we are eager to collaborate with developers from other browsers.</p> -</section><section id="what-s-the-difference-between-npapi-and-pepper"> <h3 id="what-s-the-difference-between-npapi-and-pepper">What’s the difference between NPAPI and Pepper?</h3> <p><a class="reference internal" href="/native-client/pepper_stable/index.html"><em>Pepper</em></a> (also known as PPAPI) is a new API that lets Native Client modules communicate with the browser. Pepper supports various features that don’t have robust support in NPAPI, such as event handling, out-of-process plugins, and asynchronous interfaces. Native Client has transitioned from using NPAPI to using Pepper.</p> -</section><section id="is-npapi-part-of-the-native-client-sdk"> <h3 id="is-npapi-part-of-the-native-client-sdk">Is NPAPI part of the Native Client SDK?</h3> <p>NPAPI is not supported by the Native Client SDK, and is <a class="reference external" href="http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html">deprecated in Chrome</a>.</p> -</section><section id="does-native-client-support-simd-vector-instructions"> <h3 id="does-native-client-support-simd-vector-instructions">Does Native Client support SIMD vector instructions?</h3> <p>Native Client currently supports SSE on x86 and NEON on ARM. Support for AVX on x86 is under way.</p> <p>Portable Native Client supports portable SIMD vectors, as detailed in <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#portable-simd-vectors"><em>Portable SIMD Vectors</em></a>.</p> -</section><section id="can-i-use-native-client-for-3d-graphics"> <h3 id="can-i-use-native-client-for-3d-graphics">Can I use Native Client for 3D graphics?</h3> <p>Yes. Native Client supports <a class="reference external" href="https://www.khronos.org/opengles/">OpenGL ES 2.0</a>.</p> <p>To alert the user regarding their hardware platform’s 3D feature set @@ -297,7 +278,6 @@ file</a>. This file is part of the GL wrapper supplied by the library extensions map to extensions available on other platforms, or differ very slightly (if they differ, the extension is usually CHROMIUM or ANGLE instead of EXT).</p> -</section><section id="does-native-client-support-concurrency-parallelism"> <h3 id="does-native-client-support-concurrency-parallelism">Does Native Client support concurrency/parallelism?</h3> <p>Native Client and Portable Native Client both support pthreads, C11/C++11 threads, and low-level synchronization primitives (mutex, @@ -308,9 +288,7 @@ needing to copy them, which is often a limitation of shared-nothing systems. For more information see <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#memory-model-and-atomics"><em>memory model and atomics</em></a> and <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#language-support-threading"><em>threading</em></a>.</p> <p>Native Client doesn’t support HTML5 Web Workers directly but can interact with JavaScript code which does.</p> -</section></section><section id="coming-soon"> <h2 id="coming-soon">Coming Soon</h2> -<section id="do-native-client-modules-have-access-to-external-devices"> <h3 id="do-native-client-modules-have-access-to-external-devices">Do Native Client modules have access to external devices?</h3> <p>At this time Native Client modules do not have access to serial ports, camera devices, or microphones: Native Client can only use native @@ -321,9 +299,7 @@ efforts to make these resources available inside the browser.</p> capabilities of HTML5. The goal is for Pepper and JavaScript to evolve together and stay on par with each other with respect to features and capabilities.</p> -</section></section><section id="security-and-privacy"> <h2 id="security-and-privacy">Security and Privacy</h2> -<section id="what-happens-to-my-data-when-i-use-native-client"> <h3 id="what-happens-to-my-data-when-i-use-native-client">What happens to my data when I use Native Client?</h3> <p>Users can opt-in to sending usage statistics and crash information in Chrome, which includes usage statistics and crash information about @@ -333,7 +309,6 @@ does so anonymously without sending your application’s data or its debug information.</p> <p>For additional information about privacy and Chrome, see the <a class="reference external" href="https://www.google.com/chrome/intl/en/privacy.html">Google Chrome privacy policy</a> and the <a class="reference external" href="https://www.google.com/chrome/intl/en/eula_text.html">Google Chrome Terms of Service</a>.</p> -</section><section id="how-does-native-client-prevent-sandboxed-code-from-doing-bad-things"> <h3 id="how-does-native-client-prevent-sandboxed-code-from-doing-bad-things">How does Native Client prevent sandboxed code from doing Bad Things?</h3> <p>Native Client’s sandbox works by validating the untrusted code (the compiled Native Client module) before running it. The validator checks @@ -362,7 +337,6 @@ output.</p> includes an outer sandbox that mediates system calls. For more details about both sandboxes, see <a class="reference external" href="http://research.google.com/pubs/pub34913.html">Native Client: A Sandbox for Portable, Untrusted x86 Code</a> (PDF).</p> -</section><section id="how-does-google-know-that-the-safety-measures-in-native-client-are-sufficient"> <h3 id="how-does-google-know-that-the-safety-measures-in-native-client-are-sufficient">How does Google know that the safety measures in Native Client are sufficient?</h3> <p>Google has taken several steps to ensure that Native Client’s security works, including:</p> @@ -375,20 +349,16 @@ including:</p> <p>Google is committed to making Native Client safer than JavaScript and other popular browser technologies. If you have suggestions for security improvements, let the team know, by way of the <a class="reference external" href="https://groups.google.com/group/native-client-discuss">native-client-discuss</a> mailing list.</p> -</section></section><section id="development"> <h2 id="development">Development</h2> -<section id="how-do-i-debug"> <h3 id="how-do-i-debug">How do I debug?</h3> <p>Instructions on <a class="reference internal" href="/native-client/sdk/examples.html#debugging-the-sdk-examples"><em>debugging the SDK examples</em></a> using GDB are available. You can also debug Native Client modules with some <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html"><em>alternative approaches</em></a>.</p> -</section><section id="how-do-i-build-x86-32-x86-64-or-arm-nexes"> <h3 id="how-do-i-build-x86-32-x86-64-or-arm-nexes">How do I build x86-32, x86-64 or ARM <code>.nexes</code>?</h3> <p>By default, the applications in the <code>/examples</code> folder create architecture-independent <code>.pexe</code> for Portable Native Client. To generate a <code>.nexe</code> targetting one specific architecture using the Native Client or Portable Native Client toolchains, see the <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building instructions</em></a>.</p> -</section><section id="how-can-my-web-application-determine-which-nexe-to-load"> <h3 id="how-can-my-web-application-determine-which-nexe-to-load">How can my web application determine which <code>.nexe</code> to load?</h3> <p>Your application does not need to make the decision of loading an x86-32, x86-64 or ARM <code>.nexe</code> explicitly—the Native Client runtime @@ -399,12 +369,10 @@ examples for an illustration of how to do so). Your HTML file specifies the manifest filename in the <code>src</code> attribute of the <code><embed></code> tag. You can see the way the pieces fit together by examining the examples included in the SDK.</p> -</section><section id="is-it-possible-to-build-a-native-client-module-with-just-plain-c-not-c"> <h3 id="is-it-possible-to-build-a-native-client-module-with-just-plain-c-not-c">Is it possible to build a Native Client module with just plain C (not C++)?</h3> <p>Yes. See the <code>"Hello, World!"</code> in C example in the SDK under <code>examples/tutorial/using_ppapi_simple/</code>, or the Game of Life example under <code>examples/demo/life/life.c</code>.</p> -</section><section id="what-unix-system-calls-can-i-make-through-native-client"> <h3 id="what-unix-system-calls-can-i-make-through-native-client">What UNIX system calls can I make through Native Client?</h3> <p>Native Client doesn’t directly expose any system calls from the host OS because of the inherent security risks and because the resulting @@ -413,22 +381,18 @@ Native Client provides portable cross-OS abstractions wrapping or proxying OS functionality or emulating UNIX system calls. For example, Native Client provides an <code>mmap()</code> system call that behaves much like the standard UNIX <code>mmap()</code> system call.</p> -</section><section id="is-my-favorite-third-party-library-available-for-native-client"> <h3 id="is-my-favorite-third-party-library-available-for-native-client">Is my favorite third-party library available for Native Client?</h3> <p>Google has ported several third-party libraries to Native Client; such libraries are available in the <a class="reference external" href="https://code.google.com/p/naclports">naclports</a> project. We encourage you to contribute libraries to naclports, and/or to host your own ported libraries, and to let the team know about it on <a class="reference external" href="https://groups.google.com/group/native-client-discuss">native-client-discuss</a> when you do.</p> -</section><section id="do-all-the-files-in-an-application-need-to-be-served-from-the-same-domain"> <h3 id="do-all-the-files-in-an-application-need-to-be-served-from-the-same-domain">Do all the files in an application need to be served from the same domain?</h3> <p>The <code>.nmf</code>, and <code>.nexe</code> or <code>.pexe</code> files must either be served from the same origin as the embedding page or an origin that has been configured correctly using <a class="reference external" href="http://en.wikipedia.org/wiki/Cross-origin_resource_sharing">CORS</a>.</p> <p>For applications installed from the Chrome Web Store the Web Store manifest must include the correct, verified domain of the embedding page.</p> -</section></section><section id="portability"> <h2 id="portability">Portability</h2> -<section id="do-i-have-to-do-anything-special-to-make-my-application-run-on-different-operating-systems"> <h3 id="do-i-have-to-do-anything-special-to-make-my-application-run-on-different-operating-systems">Do I have to do anything special to make my application run on different operating systems?</h3> <p>No. Native Client and Portable Native Client applications run without modification on all supported operating systems.</p> @@ -441,7 +405,6 @@ make them available on the Chrome Web Store. See <a class="reference internal" h architectures</em></a> for details about which <code>.nexe</code> files will run on which architectures.</li> </ul> -</section><section id="how-easy-is-it-to-port-my-existing-native-code-to-native-client"> <h3 id="how-easy-is-it-to-port-my-existing-native-code-to-native-client">How easy is it to port my existing native code to Native Client?</h3> <p>In most cases you won’t have to rewrite much, if any, code. The Native Client-specific tools, such as <code>pnacl-clang++</code> or <code>x86_64-nacl-g++</code>, @@ -467,9 +430,7 @@ the Native Client SDK includes a library called nacl_io which allows the application to interact with all these types of files via standard POSIX I/O functions (e.g. open/fopen/read/write/...). See <a class="reference internal" href="/native-client/devguide/coding/nacl_io.html"><em>Using NaCl I/O</em></a> for more details.</li> </ul> -</section></section><section id="troubleshooting"> -<span id="faq-troubleshooting"></span><h2 id="troubleshooting"><span id="faq-troubleshooting"></span>Troubleshooting</h2> -<section id="my-pexe-isn-t-loading-help"> +<h2 id="troubleshooting"><span id="faq-troubleshooting"></span>Troubleshooting</h2> <h3 id="my-pexe-isn-t-loading-help">My <code>.pexe</code> isn’t loading, help!</h3> <ul class="small-gap"> <li>You must use Google Chrome version 31 or greater for Portable Native @@ -482,7 +443,6 @@ SDK versions had experimental support for PNaCl, now deprecated).</li> in JavaScript with <code>navigator.mimeTypes['application/x-pnacl'] !== undefined</code>. This is preferred over checking the Chrome version.</li> </ul> -</section><section id="my-nexe-files-never-finish-loading-what-gives"> <h3 id="my-nexe-files-never-finish-loading-what-gives">My <code>.nexe</code> files never finish loading. What gives?</h3> <p>Here are ways to resolve some common problems that can prevent loading:</p> <ul class="small-gap"> @@ -515,6 +475,6 @@ select a processor-specific <code>.nexe</code> goes away with Portable Native Client.</li> <li>If things still aren’t working, <a class="reference internal" href="/native-client/help.html"><em>ask for help</em></a>!</li> </ul> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/help.html b/native_client_sdk/doc_generated/help.html index baf5440e58..f59bd39369 100644 --- a/native_client_sdk/doc_generated/help.html +++ b/native_client_sdk/doc_generated/help.html @@ -5,7 +5,6 @@ <p>Check the documentation resources below for help with common issues and problems. For additional questions, reach out to the Native Client community in the forums below. You can also <a class="reference internal" href="#report-issue"><em>report new issues</em></a> using the Native Client issue tracker.</p> -<section id="documentation"> <h2 id="documentation">Documentation</h2> <ul class="small-gap"> <li><a class="reference internal" href="/native-client/sdk/release-notes.html"><em>Release Notes</em></a>.</li> @@ -13,7 +12,6 @@ community in the forums below. You can also <a class="reference internal" href=" <li><a class="reference external" href="https://devsite.googleplex.com/native-client/community/talks">Talks, Demos, and Publications</a> (see especially Colt McAnlis’ talk on porting C++ games to Native Client).</li> </ul> -</section><section id="forums"> <h2 id="forums">Forums</h2> <ul class="small-gap"> <li>For new Native Client developers: <a class="reference external" href="http://stackoverflow.com/questions/tagged/google-nativeclient">Stack Overflow</a> is a @@ -25,8 +23,7 @@ group for detailed technical discussions about bugs and other Native Client issues. * For announcements, follow the <a class="reference external" href="http://groups.google.com/group/native-client-announce">native-client-announce mailing list</a>.</li> <li>For 140 character goodness follow <a class="reference external" href="https://twitter.com/nativeclient">@nativeclient</a> on Twitter.</li> </ul> -</section><section id="issue-tracker"> -<span id="report-issue"></span><h2 id="issue-tracker"><span id="report-issue"></span>Issue tracker</h2> +<h2 id="issue-tracker"><span id="report-issue"></span>Issue tracker</h2> <p>To report a new issue:</p> <ol class="arabic simple"> <li>Go to the <a class="reference external" href="https://code.google.com/p/nativeclient/issues">Native Client issue tracker</a> for a Native Client @@ -45,6 +42,6 @@ the issue form and click the “Submit issue” button. You can report:< </ul> </li> </ol> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/index.html b/native_client_sdk/doc_generated/index.html index 393827bb60..e46695cb81 100644 --- a/native_client_sdk/doc_generated/index.html +++ b/native_client_sdk/doc_generated/index.html @@ -30,8 +30,7 @@ src="//www.youtube.com/embed/MvKEomoiKBA?rel=0" frameborder="0"></iframe> <li>Write-once, run-anywhere code portability across all user architectures.</li> </ul></div> </div> -</div><section id="get-started-with-native-client"> -<h2 id="get-started-with-native-client">Get started with Native Client</h2> +</div><h2 id="get-started-with-native-client">Get started with Native Client</h2> <div class="big-intro"><ol class="arabic simple"> <li><a class="reference internal" href="/native-client/sdk/download.html"><em>Download the Native Client SDK</em></a>.</li> <li>Read the <a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a>.</li> @@ -42,6 +41,6 @@ src="//www.youtube.com/embed/MvKEomoiKBA?rel=0" frameborder="0"></iframe> <div class="big-intro" style="clear: both;"><p>Send us questions, comments, and feedback: <a class="reference external" href="https://groups.google.com/forum/#!forum/native-client-discuss">native-client-discuss</a>.</p> </div> -</div></section></section> +</div></section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/io2014.html b/native_client_sdk/doc_generated/io2014.html index 5b9c66d966..285f7c5c2e 100644 --- a/native_client_sdk/doc_generated/io2014.html +++ b/native_client_sdk/doc_generated/io2014.html @@ -2,7 +2,6 @@ <section id="building-a-nacl-app"> <span id="io2014"></span><h1 id="building-a-nacl-app"><span id="io2014"></span>Building a NaCl App</h1> -<section id="in-the-browser"> <h2 id="in-the-browser">In the browser!</h2> <p>Follow along with Brad Nelson’s Google I/O 2014 talk. Explore our new in-browser development environment and debugger.</p> @@ -10,8 +9,7 @@ Explore our new in-browser development environment and debugger.</p> all in your desktop web browser or on a Chromebook. Work either on-line or off-line!</p> <iframe class="video" width="500" height="281" -src="//www.youtube.com/embed/OzNuzBDEWzk?rel=0" frameborder="0"></iframe><section id="work-in-progress"> -<h3 id="work-in-progress">Work in Progress</h3> +src="//www.youtube.com/embed/OzNuzBDEWzk?rel=0" frameborder="0"></iframe><h3 id="work-in-progress">Work in Progress</h3> <p>These development tools are a work in progress, see <a class="reference internal" href="#feature-status">Feature Status</a>. At this point, they are a learning tool and demonstration of NaCl’s flexibility, but are not the recommended tools for a production application. @@ -23,8 +21,7 @@ we currently recommend you use the NOTE: The NaCl Development Environment is not yet stable. Ideally user data is preserved, but currently it can be lost during updates or sporadically. We're working to resolve this. -</font></b></section><section id="installation"> -<h3 id="installation">Installation</h3> +</font></b><h3 id="installation">Installation</h3> <p>The setup process currently requires several steps. We’re working to reduce the number of steps in future releases. As the process gets easier, we’ll update this page.</p> @@ -61,7 +58,6 @@ Once you’re ready to apply the debugger, follow these steps:</p> temporarily and try again.</li> </ul> </div></blockquote> -</section><section id="editor"> <h3 id="editor">Editor</h3> <p>To follow along in this tutorial, you’ll need to use a text editor to modify various files in our development environment. @@ -83,7 +79,6 @@ $ vim <filename> <p>Here’s an online <a class="reference external" href="http://www.openvim.com/tutorial.html">vim tutorial</a>.</p> </li> </ul> -</section><section id="git-setup"> <h3 id="git-setup">Git Setup</h3> <p>This tutorial also uses a revision control program called <a class="reference external" href="http://en.wikipedia.org/wiki/Git_(software)">git</a>. @@ -99,7 +94,6 @@ git config --global user.email johndoe@example.com <pre class="prettyprint"> source ~/.bashrc </pre> -</section><section id="tour-follow-the-video"> <h3 id="tour-follow-the-video">Tour (follow the video)</h3> <p>Create a working directory and go into it:</p> <pre class="prettyprint"> @@ -172,7 +166,6 @@ $ make serve <p>Then, navigate to <a class="reference external" href="http://localhost:5103/">http://localhost:5103/</a> to test the demo.</p> <p>If you follow along with the demo video, you will discover the sample crashes when you change the thread count.</p> -</section><section id="debugging"> <h3 id="debugging">Debugging</h3> <p>If you haven’t installed the debugger at this point, skip to the next section.</p> <p>At this point, if you have the debugger installed, you should be able to open @@ -195,7 +188,6 @@ add-symbol-file irt remote get nexe nexe add-symbol-file nexe </pre> -</section><section id="fix-it-up"> <h3 id="fix-it-up">Fix it up</h3> <p>Return to the development environment and stop the test server, by pressing Ctrl-C.</p> @@ -217,13 +209,11 @@ $ git log <pre class="prettyprint"> $ make serve </pre> -</section><section id="thanks"> <h3 id="thanks">Thanks</h3> <p>Thanks for checking out our environment. Things are rapidly changing and in the coming months you can expect to see further improvements and filling out of our platform and library support.</p> <p>Check back at this page for the latest status.</p> -</section><section id="feature-status"> <h3 id="feature-status">Feature Status</h3> <p>Here is a summary of feature status. We hope to overcome these limitations in the near future:</p> @@ -275,6 +265,6 @@ in the near future:</p> </li> </ul> </div></blockquote> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/nacl-and-pnacl.html b/native_client_sdk/doc_generated/nacl-and-pnacl.html index 27187ba769..283296d88f 100644 --- a/native_client_sdk/doc_generated/nacl-and-pnacl.html +++ b/native_client_sdk/doc_generated/nacl-and-pnacl.html @@ -12,8 +12,7 @@ <li><a class="reference internal" href="#when-to-use-nacl" id="id6">When to use NaCl</a></li> </ul> -</div><section id="native-client-nacl"> -<h2 id="native-client-nacl">Native Client (NaCl)</h2> +</div><h2 id="native-client-nacl">Native Client (NaCl)</h2> <p>Native Client enables the execution of native code securely inside web applications through the use of advanced <a class="reference external" href="/native-client/community/talks#research">Software Fault Isolation (SFI) techniques</a>. Since its launch in @@ -34,7 +33,6 @@ Architecture-specific executables are clearly not a good fit for distribution on the web. As a consequence, Native Client has been restricted to applications and browser extensions that are installed through the Chrome Web Store.</p> -</section><section id="portable-native-client-pnacl"> <h2 id="portable-native-client-pnacl">Portable Native Client (PNaCl)</h2> <p>PNaCl solves the portability problem by splitting the compilation process into two parts:</p> @@ -67,7 +65,6 @@ application—it does not have to be distributed through the Chrome Web Store.</p> <p>PNaCl is a new technology, and as such it still has a few limitations as compared to NaCl. These limitations are described below.</p> -</section><section id="when-to-use-pnacl"> <h2 id="when-to-use-pnacl">When to use PNaCl</h2> <p>PNaCl is the preferred toolchain for Native Client, and the only way to deploy Native Client modules on the open web. Unless your project is subject to one @@ -85,8 +82,7 @@ you can still use the PNaCl toolchain and distribute your application through the Chrome Web Store, and thereby take advantage of the conveniences of PNaCl, such as not having to explicitly compile your application for all supported architectures.</p> -</section><section id="when-to-use-nacl"> -<span id="id2"></span><h2 id="when-to-use-nacl"><span id="id2"></span>When to use NaCl</h2> +<h2 id="when-to-use-nacl"><span id="id2"></span>When to use NaCl</h2> <p>The limitations below apply to the current release of PNaCl. If any of these limitations are critical for your application, you should use non-portable NaCl:</p> @@ -103,6 +99,6 @@ Work is under way to enable dynamic linking in future versions of PNaCl.</li> like taking the address of a label for computed <code>goto</code>, or nested functions.</li> </ul> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/overview.html b/native_client_sdk/doc_generated/overview.html index f85cd07612..b9d48dbcb1 100644 --- a/native_client_sdk/doc_generated/overview.html +++ b/native_client_sdk/doc_generated/overview.html @@ -23,8 +23,7 @@ <li><a class="reference internal" href="#where-to-start" id="id12">Where to start</a></li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p><strong>Native Client</strong> (NaCl) is an open-source technology for running native compiled code in the browser, with the goal of maintaining the portability and safety that users expect from web applications. Native Client expands web @@ -40,7 +39,6 @@ by the SDK. The NaCl SDK currently supports C and C++; as compilers for additional languages are developed, the SDK will be updated to support those languages as well.</p> <img alt="/native-client/images/web-app-with-nacl.png" src="/native-client/images/web-app-with-nacl.png" /> -</section><section id="why-use-native-client"> <h2 id="why-use-native-client">Why use Native Client?</h2> <p>Native Client open-source technology is designed to run compiled code securely inside a browser at near-native speeds. Native Client puts web @@ -73,7 +71,6 @@ Native Client also allows applications to harness all available CPU cores via a threading API; this enables demanding applications such as console-quality games to run inside the browser.</li> </ul> -</section><section id="common-use-cases"> <h2 id="common-use-cases">Common use cases</h2> <p>Typical use cases for Native Client include the following:</p> <ul class="small-gap"> @@ -108,8 +105,7 @@ into web applications—it’s up to you to decide to what extent to use Use of Native Client covers the full spectrum from complete applications to small optimized routines that accelerate vital parts of web apps.</li> </ul> -</section><section id="how-native-client-works"> -<span id="link-how-nacl-works"></span><h2 id="how-native-client-works"><span id="link-how-nacl-works"></span>How Native Client works</h2> +<h2 id="how-native-client-works"><span id="link-how-nacl-works"></span>How Native Client works</h2> <p>Native Client is an umbrella name for a set of interrelated software components that work together to provide a way to develop C/C++ applications and run them securely on the web.</p> @@ -133,7 +129,6 @@ Native Client. Developers use a nacl-gcc based toolchain to produce multiple architecture-dependent (<strong>nexe</strong>) modules, which are packaged into an application. At runtime, the browser decides which nexe to load based on the architecture of the client machine.</p> -<section id="security"> <h3 id="security">Security</h3> <p>Since Native Client permits the execution of native code on client machines, special security measures have to be implemented:</p> @@ -150,7 +145,6 @@ restricted permissions. The only interaction between this process and the outside world is through sanctioned browser interfaces. Because of the combination of the NaCl sandbox and the Chrome sandbox, we say that Native Client employs a double sandbox design.</p> -</section><section id="portability"> <h3 id="portability">Portability</h3> <p>Portable Native Client (PNaCl, prounounced “pinnacle”) employs state-of-the-art compiler technology to compile C/C++ source code to a portable bitcode @@ -170,8 +164,7 @@ used as part of applications and extensions that are installed from the Chrome Web Store.</p> <p>For more details on the difference between NaCl and PNaCl, see <a class="reference internal" href="/native-client/nacl-and-pnacl.html"><em>NaCl and PNaCl</em></a>.</p> -</section><section id="toolchains"> -<span id="id1"></span><h3 id="toolchains"><span id="id1"></span>Toolchains</h3> +<h3 id="toolchains"><span id="id1"></span>Toolchains</h3> <p>A toolchain is a set of tools used to create an application from a set of source files. In the case of Native Client, a toolchain consists of a compiler, linker, assembler and other tools that are used to convert an @@ -185,8 +178,7 @@ application written in C/C++ into a module that is loadable by the browser.</p> <p>The PNaCl toolchain is recommended for most applications. The nacl-gcc toolchain should only be used for applications that will not be distributed on the open web.</p> -</section></section><section id="native-client-in-a-web-application"> -<span id="link-nacl-in-web-apps"></span><h2 id="native-client-in-a-web-application"><span id="link-nacl-in-web-apps"></span>Native Client in a web application</h2> +<h2 id="native-client-in-a-web-application"><span id="link-nacl-in-web-apps"></span>Native Client in a web application</h2> <p id="application-files">A Native Client application consists of a set of files:</p> <ul class="small-gap"> <li><strong>HTML</strong>, <strong>CSS</strong>, and <strong>JavaScript</strong> files, as in any modern web @@ -200,8 +192,7 @@ through an <code><embed></code> tag, as shown in the figure below.</li> </ul> <img alt="/native-client/images/nacl-in-a-web-app.png" src="/native-client/images/nacl-in-a-web-app.png" /> <p>For more details, see <a class="reference internal" href="/native-client/devguide/coding/application-structure.html"><em>Application Structure</em></a>.</p> -<section id="pepper-plugin-api"> -<span id="link-pepper"></span><h3 id="pepper-plugin-api"><span id="link-pepper"></span>Pepper Plugin API</h3> +<h3 id="pepper-plugin-api"><span id="link-pepper"></span>Pepper Plugin API</h3> <p>The Pepper Plugin API (PPAPI), called <strong>Pepper</strong> for convenience, is an open-source, cross-platform C/C++ API for web browser plugins. From the point of view of Native Client, Pepper allows a C/C++ module to communicate with @@ -220,7 +211,6 @@ capabilities, including:</p> <p>Pepper includes both a C API and a C++ API. The C++ API is a set of bindings written on top of the C API. For additional information about Pepper, see <a class="reference external" href="http://code.google.com/p/ppapi/wiki/Concepts">Pepper Concepts</a>.</p> -</section></section><section id="versioning"> <h2 id="versioning">Versioning</h2> <p>Chrome is released on a six week cycle, and developer versions of Chrome are pushed to the public beta channel three weeks before each release. As with any @@ -230,11 +220,10 @@ However, modules compiled for one version of Pepper/Chrome should work with subsequent versions of Pepper/Chrome. The SDK includes multiple versions of the Pepper APIs to help developers make adjustments to API changes and take advantage of new features: <a class="reference external" href="/native-client/pepper_stable">stable</a>, <a class="reference external" href="/native-client/pepper_beta">beta</a> and <a class="reference external" href="/native-client/pepper_dev">dev</a>.</p> -</section><section id="where-to-start"> <h2 id="where-to-start">Where to start</h2> <p>The <a class="reference internal" href="/native-client/quick-start.html"><em>Quick Start</em></a> document provides links to downloads and documentation that should help you get started with developing and distributing Native Client applications.</p> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_beta/c/index.html b/native_client_sdk/doc_generated/pepper_beta/c/index.html index 22e8e4d05f..9f032ddf9b 100644 --- a/native_client_sdk/doc_generated/pepper_beta/c/index.html +++ b/native_client_sdk/doc_generated/pepper_beta/c/index.html @@ -4,7 +4,6 @@ <h1 id="pepper-c-api-reference-beta">Pepper C API Reference (Beta)</h1> <p>This page lists the C API for Pepper 36. Apps that use this API can run in Chrome 36 or higher.</p> -<section id="id1"> <h2 id="id1"><a class="reference external" href="group___interfaces.html">Interfaces</a></h2> <blockquote> <div><ul class="small-gap"> @@ -61,7 +60,6 @@ run in Chrome 36 or higher.</p> <li><a class="reference external" href="struct_p_p_p___mouse_lock__1__0.html">PPP_MouseLock</a></li> </ul> </div></blockquote> -</section><section id="id2"> <h2 id="id2"><a class="reference external" href="group___structs.html">Structures</a></h2> <blockquote> <div><ul class="small-gap"> @@ -89,15 +87,10 @@ run in Chrome 36 or higher.</p> <li><a class="reference external" href="union_p_p___var_value.html">PP_VarValue</a></li> </ul> </div></blockquote> -</section><section id="id3"> <h2 id="id3"><a class="reference external" href="group___functions.html">Functions</a></h2> -</section><section id="id4"> <h2 id="id4"><a class="reference external" href="group___enums.html">Enums</a></h2> -</section><section id="id5"> <h2 id="id5"><a class="reference external" href="group___typedefs.html">Typedefs</a></h2> -</section><section id="id6"> <h2 id="id6"><a class="reference external" href="globals_defs.html">Macros</a></h2> -</section><section id="files"> <h2 id="files">Files</h2> <blockquote> <div><ul class="small-gap"> @@ -170,6 +163,6 @@ run in Chrome 36 or higher.</p> <li><a class="reference external" href="ppp__mouse__lock_8h.html">ppp_mouse_lock.h</a></li> </ul> </div></blockquote> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_beta/cpp/index.html b/native_client_sdk/doc_generated/pepper_beta/cpp/index.html index 9ee0bd69ca..090008d314 100644 --- a/native_client_sdk/doc_generated/pepper_beta/cpp/index.html +++ b/native_client_sdk/doc_generated/pepper_beta/cpp/index.html @@ -4,7 +4,6 @@ <h1 id="pepper-c-api-reference-beta">Pepper C++ API Reference (Beta)</h1> <p>This page lists the C++ API for Pepper 36. Apps that use this API can run in Chrome 36 or higher.</p> -<section id="id1"> <h2 id="id1"><a class="reference external" href="inherits.html">Classes</a></h2> <blockquote> <div><ul class="small-gap"> @@ -67,7 +66,6 @@ run in Chrome 36 or higher.</p> <li><a class="reference external" href="classpp_1_1internal_1_1_directory_entry_array_output_adapter_with_storage.html">Internal::DirectoryEntryArrayOutputAdapterWithStorage</a></li> </ul> </div></blockquote> -</section><section id="files"> <h2 id="files">Files</h2> <blockquote> <div><ul class="small-gap"> @@ -125,6 +123,6 @@ run in Chrome 36 or higher.</p> <li><a class="reference external" href="websocket_8h.html">websocket.h</a></li> </ul> </div></blockquote> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_beta/index.html b/native_client_sdk/doc_generated/pepper_beta/index.html index e814190f63..cc2c4eb515 100644 --- a/native_client_sdk/doc_generated/pepper_beta/index.html +++ b/native_client_sdk/doc_generated/pepper_beta/index.html @@ -4,10 +4,8 @@ <h1 id="pepper-api-reference-beta">Pepper API Reference (Beta)</h1> <p>This page lists the API for Pepper 36. Apps that use this API can run in Chrome 36 or higher.</p> -<section id="pepper-c-api-reference"> <h2 id="pepper-c-api-reference"><a class="reference internal" href="/native-client/pepper_beta/c/index.html#pepper-beta-c-index"><em>Pepper C API Reference</em></a></h2> -</section><section id="id1"> <h2 id="id1"><a class="reference internal" href="/native-client/pepper_beta/cpp/index.html#pepper-beta-cpp-index"><em>Pepper C++ API Reference</em></a></h2> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_dev/c/index.html b/native_client_sdk/doc_generated/pepper_dev/c/index.html index aad2fc83f6..1a2f576320 100644 --- a/native_client_sdk/doc_generated/pepper_dev/c/index.html +++ b/native_client_sdk/doc_generated/pepper_dev/c/index.html @@ -4,7 +4,6 @@ <h1 id="pepper-c-api-reference-dev">Pepper C API Reference (Dev)</h1> <p>This page lists the C API for Pepper 37. Apps that use this API can run in Chrome 37 or higher.</p> -<section id="id1"> <h2 id="id1"><a class="reference external" href="group___interfaces.html">Interfaces</a></h2> <blockquote> <div><ul class="small-gap"> @@ -64,7 +63,6 @@ run in Chrome 37 or higher.</p> <li><a class="reference external" href="struct_p_p_p___mouse_lock__1__0.html">PPP_MouseLock</a></li> </ul> </div></blockquote> -</section><section id="id2"> <h2 id="id2"><a class="reference external" href="group___structs.html">Structures</a></h2> <blockquote> <div><ul class="small-gap"> @@ -94,15 +92,10 @@ run in Chrome 37 or higher.</p> <li><a class="reference external" href="union_p_p___var_value.html">PP_VarValue</a></li> </ul> </div></blockquote> -</section><section id="id3"> <h2 id="id3"><a class="reference external" href="group___functions.html">Functions</a></h2> -</section><section id="id4"> <h2 id="id4"><a class="reference external" href="group___enums.html">Enums</a></h2> -</section><section id="id5"> <h2 id="id5"><a class="reference external" href="group___typedefs.html">Typedefs</a></h2> -</section><section id="id6"> <h2 id="id6"><a class="reference external" href="globals_defs.html">Macros</a></h2> -</section><section id="files"> <h2 id="files">Files</h2> <blockquote> <div><ul class="small-gap"> @@ -178,6 +171,6 @@ run in Chrome 37 or higher.</p> <li><a class="reference external" href="ppp__mouse__lock_8h.html">ppp_mouse_lock.h</a></li> </ul> </div></blockquote> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_dev/cpp/index.html b/native_client_sdk/doc_generated/pepper_dev/cpp/index.html index 491ab5ca7b..d20268f588 100644 --- a/native_client_sdk/doc_generated/pepper_dev/cpp/index.html +++ b/native_client_sdk/doc_generated/pepper_dev/cpp/index.html @@ -4,7 +4,6 @@ <h1 id="pepper-c-api-reference-dev">Pepper C++ API Reference (Dev)</h1> <p>This page lists the C++ API for Pepper 37. Apps that use this API can run in Chrome 37 or higher.</p> -<section id="id1"> <h2 id="id1"><a class="reference external" href="inherits.html">Classes</a></h2> <blockquote> <div><ul class="small-gap"> @@ -71,7 +70,6 @@ run in Chrome 37 or higher.</p> <li><a class="reference external" href="classpp_1_1internal_1_1_directory_entry_array_output_adapter_with_storage.html">Internal::DirectoryEntryArrayOutputAdapterWithStorage</a></li> </ul> </div></blockquote> -</section><section id="files"> <h2 id="files">Files</h2> <blockquote> <div><ul class="small-gap"> @@ -131,6 +129,6 @@ run in Chrome 37 or higher.</p> <li><a class="reference external" href="websocket_8h.html">websocket.h</a></li> </ul> </div></blockquote> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_dev/index.html b/native_client_sdk/doc_generated/pepper_dev/index.html index 385188ca5f..f78b69b81d 100644 --- a/native_client_sdk/doc_generated/pepper_dev/index.html +++ b/native_client_sdk/doc_generated/pepper_dev/index.html @@ -4,10 +4,8 @@ <h1 id="pepper-api-reference-dev">Pepper API Reference (Dev)</h1> <p>This page lists the API for Pepper 37. Apps that use this API can run in Chrome 37 or higher.</p> -<section id="pepper-c-api-reference"> <h2 id="pepper-c-api-reference"><a class="reference internal" href="/native-client/pepper_dev/c/index.html#pepper-dev-c-index"><em>Pepper C API Reference</em></a></h2> -</section><section id="id1"> <h2 id="id1"><a class="reference internal" href="/native-client/pepper_dev/cpp/index.html#pepper-dev-cpp-index"><em>Pepper C++ API Reference</em></a></h2> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_stable/c/index.html b/native_client_sdk/doc_generated/pepper_stable/c/index.html index 949b197828..b8605f2c0c 100644 --- a/native_client_sdk/doc_generated/pepper_stable/c/index.html +++ b/native_client_sdk/doc_generated/pepper_stable/c/index.html @@ -4,7 +4,6 @@ <h1 id="pepper-c-api-reference-stable">Pepper C API Reference (Stable)</h1> <p>This page lists the C API for Pepper 35. Apps that use this API can run in Chrome 35 or higher.</p> -<section id="id1"> <h2 id="id1"><a class="reference external" href="group___interfaces.html">Interfaces</a></h2> <blockquote> <div><ul class="small-gap"> @@ -60,7 +59,6 @@ run in Chrome 35 or higher.</p> <li><a class="reference external" href="struct_p_p_p___mouse_lock__1__0.html">PPP_MouseLock</a></li> </ul> </div></blockquote> -</section><section id="id2"> <h2 id="id2"><a class="reference external" href="group___structs.html">Structures</a></h2> <blockquote> <div><ul class="small-gap"> @@ -87,15 +85,10 @@ run in Chrome 35 or higher.</p> <li><a class="reference external" href="union_p_p___var_value.html">PP_VarValue</a></li> </ul> </div></blockquote> -</section><section id="id3"> <h2 id="id3"><a class="reference external" href="group___functions.html">Functions</a></h2> -</section><section id="id4"> <h2 id="id4"><a class="reference external" href="group___enums.html">Enums</a></h2> -</section><section id="id5"> <h2 id="id5"><a class="reference external" href="group___typedefs.html">Typedefs</a></h2> -</section><section id="id6"> <h2 id="id6"><a class="reference external" href="globals_defs.html">Macros</a></h2> -</section><section id="files"> <h2 id="files">Files</h2> <blockquote> <div><ul class="small-gap"> @@ -166,6 +159,6 @@ run in Chrome 35 or higher.</p> <li><a class="reference external" href="ppp__mouse__lock_8h.html">ppp_mouse_lock.h</a></li> </ul> </div></blockquote> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_stable/cpp/index.html b/native_client_sdk/doc_generated/pepper_stable/cpp/index.html index 3e5bb8b6b7..61e49f7fb8 100644 --- a/native_client_sdk/doc_generated/pepper_stable/cpp/index.html +++ b/native_client_sdk/doc_generated/pepper_stable/cpp/index.html @@ -4,7 +4,6 @@ <h1 id="pepper-c-api-reference-stable">Pepper C++ API Reference (Stable)</h1> <p>This page lists the C++ API for Pepper 35. Apps that use this API can run in Chrome 35 or higher.</p> -<section id="id1"> <h2 id="id1"><a class="reference external" href="inherits.html">Classes</a></h2> <blockquote> <div><ul class="small-gap"> @@ -68,7 +67,6 @@ run in Chrome 35 or higher.</p> <li><a class="reference external" href="classpp_1_1internal_1_1_directory_entry_array_output_adapter_with_storage.html">Internal::DirectoryEntryArrayOutputAdapterWithStorage</a></li> </ul> </div></blockquote> -</section><section id="files"> <h2 id="files">Files</h2> <blockquote> <div><ul class="small-gap"> @@ -125,6 +123,6 @@ run in Chrome 35 or higher.</p> <li><a class="reference external" href="websocket_8h.html">websocket.h</a></li> </ul> </div></blockquote> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/pepper_stable/index.html b/native_client_sdk/doc_generated/pepper_stable/index.html index 9451824357..11a4fb0b02 100644 --- a/native_client_sdk/doc_generated/pepper_stable/index.html +++ b/native_client_sdk/doc_generated/pepper_stable/index.html @@ -4,10 +4,8 @@ <h1 id="pepper-api-reference-stable">Pepper API Reference (Stable)</h1> <p>This page lists the API for Pepper 35. Apps that use this API can run in Chrome 35 or higher.</p> -<section id="pepper-c-api-reference"> <h2 id="pepper-c-api-reference"><a class="reference internal" href="/native-client/pepper_stable/c/index.html#pepper-stable-c-index"><em>Pepper C API Reference</em></a></h2> -</section><section id="id1"> <h2 id="id1"><a class="reference internal" href="/native-client/pepper_stable/cpp/index.html#pepper-stable-cpp-index"><em>Pepper C++ API Reference</em></a></h2> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/publications-and-presentations.html b/native_client_sdk/doc_generated/publications-and-presentations.html index b8c0858dbd..0d174e07dd 100644 --- a/native_client_sdk/doc_generated/publications-and-presentations.html +++ b/native_client_sdk/doc_generated/publications-and-presentations.html @@ -4,7 +4,6 @@ <span id="id1"></span><h1 id="publications-and-presentations"><span id="id1"></span>Publications and Presentations</h1> <p>This page lists Native Client and Portable Native Client talks, demos, and publications from various conferences and academic symposiums.</p> -<section id="recent-talks-and-demos"> <h2 id="recent-talks-and-demos">Recent talks and demos</h2> <table border="1" class="docutils"> <colgroup> @@ -63,7 +62,6 @@ Porting Your C++ Game to Native Client</td> </tr> </tbody> </table> -</section><section id="publications"> <h2 id="publications">Publications</h2> <table border="1" class="docutils"> <colgroup> @@ -102,19 +100,16 @@ Fullagar</td> </tr> </tbody> </table> -</section><section id="external-publications"> <h2 id="external-publications">External Publications</h2> <p>In these articles outside developers and Google engineers describe their experience porting libraries and applications to Native Client and Portable Native Client. They share their insights and provide some tips and instructions for how to port your own code.</p> -<section id="porting-nebula3-to-portable-native-client"> <h3 id="porting-nebula3-to-portable-native-client">Porting Nebula3 to Portable Native Client</h3> <p>Andre Weissflog ported his Nebula3 engine to Portable Native Client (see <a class="reference external" href="http://www.flohofwoe.net/demos.html">his demos</a>). He discusses <a class="reference external" href="http://flohofwoe.blogspot.de/2013/08/emscripten-and-pnacl-build-systems.html">build systems</a> and <a class="reference external" href="http://flohofwoe.blogspot.de/2013/09/emscripten-and-pnacl-app-entry-in-pnacl.html">app entry</a>.</p> -</section><section id="porting-go-home-dinosaurs"> <h3 id="porting-go-home-dinosaurs">Porting Go Home Dinosaurs</h3> <p><a class="reference external" href="http://firehosegames.com">Fire Hose Games</a> developed a new webgame <a class="reference external" href="https://chrome.google.com/webstore/detail/icefnknicgejiphafapflechfoeelbeo">Go Home Dinosaurs</a>. @@ -122,20 +117,18 @@ It features tower defense, dinosaurs, and good old fashioned BBQ. This article explains their experiences developing for Native Client including useful lessons learned to help you get started.</p> <p><a class="reference external" href="http://www.gamasutra.com/view/feature/175210/the_ins_and_outs_of_native_client.php">Read more</a></p> -</section><section id="porting-zombie-track-meat"> <h3 id="porting-zombie-track-meat">Porting Zombie Track Meat</h3> <p><a class="reference external" href="http://www.fuzzycubesoftware.com">Fuzzycube Software</a>, traditionally a mobile game development studio, talks about their adventure into the web, porting the undead decathlon <a class="reference external" href="https://chrome.google.com/webstore/detail/jmfhnfnjfdoplkgbkmibfkdjolnemfdk/reviews">Zombie Track Meat</a> from Objective C to Native Client.</p> <p><a class="reference external" href="http://fuzzycube.blogspot.com/2012/04/zombie-track-meat-post-mortem.html">Read more</a></p> -</section><section id="porting-airmech"> <h3 id="porting-airmech">Porting AirMech</h3> <p><a class="reference external" href="http://carbongames.com/">Carbon Games</a> chose Native Client as a solution for cross-platform delivery of their PC game <a class="reference external" href="https://chrome.google.com/webstore/detail/hdahlabpinmfcemhcbcfoijcpoalfgdn">AirMech</a> to Linux and Macintosh in lieu of native ports. They describe the porting process on their blog.</p> <p><a class="reference external" href="http://carbongames.com/2012/01/Native-Client">Read more</a></p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/design-docs.html b/native_client_sdk/doc_generated/reference/design-docs.html new file mode 100644 index 0000000000..aa5b1edf9f --- /dev/null +++ b/native_client_sdk/doc_generated/reference/design-docs.html @@ -0,0 +1,56 @@ +{{+bindTo:partials.standard_nacl_article}} + +<section id="design-documents"> +<h1 id="design-documents">Design Documents</h1> +<p>This is a list of design documents for Native Client. This list +generally covers designs that were implemented. It does not cover +PPAPI (Pepper).</p> +<p>Dynamic loading and linking:</p> +<ul class="small-gap"> +<li><a class="reference external" href="http://code.google.com/p/nativeclient/wiki/DynamicLoadingOptions">Dynamic loading: Options for supporting dynamic loading, and how they interact with dynamic libraries</a> (2010)</li> +</ul> +<p>Handling faults (hardware exceptions) in untrusted code:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1T2KQitbOBz_ALQtr4ONcZcSNCIKNla3DI7t6dMcx5AE/edit">NaCl untrusted fault handling: guide to the implementation</a></li> +</ul> +<p>Sandbox security on Windows:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://src.chromium.org/viewvc/native_client/trunk/src/native_client/documentation/windows_ntdll_patch.txt?revision=HEAD">Native Client’s NTDLL patch on x86-64 Windows</a> (2012)</li> +</ul> +<p>Debugging using GDB:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1OtVmgJFC7X7aa57DnyiL4V10vAVax_vcRJp4Mw86lIU/edit">Providing a GDB debug stub integrated into native_client</a> (2012). This was the main design doc for NaCl’s GDB debug stub.</li> +<li><a class="reference external" href="https://docs.google.com/a/google.com/document/d/1tu2FEA4EKhBH669iUgRZBDBcEd6jzNQ-0OVn9JI4_qk/edit">Native Client Support for Debugging, Crash Reporting and Hardware Exception Handling – high level design</a> (Jan 2012)</li> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/19qkl5R4lg-AIDf648Ml-gLRq6eZscjvvdMNWkVu2wLk/edit">NaCl: three kinds of crash handling</a> (2012). This is an earlier document. It contains notes on trusted vs. untrusted crash handling, vs. GDB support.</li> +</ul> +<p>PNaCl:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/google.com/document/d/1xUlWyXnaRnIUBnmKdOBkgq2O9OqfvaRBLaz82pNdKt0/edit">Stability of the PNaCl bitcode ABI</a> (2013). This is an overview of ABI stability issues and the features of LLVM IR that PNaCl is removing.</li> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1HvZJVwS9KeTc0jUvoQjbLapRbStHk3mZ0rPDUHNN96Y/edit">Incrementally simplifying the PNaCl bitcode format</a> (2013)</li> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1Bub1bV_IIDZDhdld-zTULE2Sv0KNbOXk33KOW8o0aR4/edit">SJLJ EH: C++ exception handling in PNaCl using setjmp()+longjmp()</a> (2013)</li> +</ul> +<p>Security hardening:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1eskaI4353XdsJQFJLRnZzb_YIESQx4gNRzf31dqXVG8/edit">Hiding PNaCl’s x86-64 sandbox base address</a> (2013). This was part of the security hardening we did for enabling PNaCl on the open web.</li> +</ul> +<p>MIPS support:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://code.google.com/p/nativeclient/issues/attachmentText?id=2275&aid=22750018000&name=native-client-mips-0.4.txt">Design for the NaCl MIPS sandbox</a> (2012)</li> +</ul> +<p>Cleanup work:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1lycqf4yPMC84011yvuyO_50V8c8COQ8dAe5rNvbeB9o/edit">Removing NaCl’s dependency on Chromium</a> (2012)</li> +</ul> +<p>DEPS rolls:</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1jHoLo9I3CCS1_-4KlIq1OiEMv9cmMuXES2Z9JVpmPtY/edit">Semi-automated NaCl DEPS rolls: Updates to nacl_revision field in Chromium’s DEPS file</a> (2013). This is a description of current practice rather than a design doc.</li> +</ul> +<h2 id="obsolete-not-implemented">Obsolete (not implemented)</h2> +<p>PNaCl multi-threading support: The following proposals do not reflect what was implemented in PNaCl in the end. They are listed here for historical reference.</p> +<ul class="small-gap"> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1HcRiGOaaPLk7pQrGnjXceoM7Px3IwOjjwdiVvJVQNr4/edit">Multi-threading support for a first release of PNaCl</a> (2013): Proposal for mutex_v2/cond_v2 IRT interfaces.</li> +<li><a class="reference external" href="https://docs.google.com/a/chromium.org/document/d/1HcRiGOaaPLk7pQrGnjXceoM7Px3IwOjjwdiVvJVQNr4/edit">Explicit vs. implicit atomicity guarantees in PNaCl</a> (2013): Discussion about how to handle atomic memory operations.</li> +</ul> +</section> + +{{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/nacl-manifest-format.html b/native_client_sdk/doc_generated/reference/nacl-manifest-format.html index 340913d3bf..b796f0cc4c 100644 --- a/native_client_sdk/doc_generated/reference/nacl-manifest-format.html +++ b/native_client_sdk/doc_generated/reference/nacl-manifest-format.html @@ -23,13 +23,11 @@ </li> </ul> -</div><section id="overview"> -<h2 id="overview">Overview</h2> +</div><h2 id="overview">Overview</h2> <p>Every Native Client application has a <a class="reference external" href="http://www.json.org/">JSON-formatted</a> NaCl Manifest File (<code>nmf</code>). The <code>nmf</code> tells the browser where to download and load your Native Client application files and libraries. The file can also contain configuration options.</p> -</section><section id="field-summary"> <h2 id="field-summary">Field summary</h2> <p>The following shows the supported top-level manifest fields. There is one section that discusses each field in detail. The only field that is required @@ -43,9 +41,7 @@ is the <code>program</code> field.</p> "files": { ... } } </pre> -</section><section id="field-details"> <h2 id="field-details">Field details</h2> -<section id="program"> <h3 id="program">program</h3> <p>The <code>program</code> field specifies the main program that will be loaded in the Native Client runtime environment. For a Portable Native Client @@ -56,7 +52,6 @@ are “arm”, “x86-32”, and “x86-64”). For a dy <code>program</code> is the dynamic loader used to load the dynamic executable and its dynamic libraries. See the <a class="reference internal" href="#nmf-url-resolution"><em>semantics</em></a> section for the rules on URL resolution.</p> -<section id="example-of-a-program-for-portable-native-client"> <h4 id="example-of-a-program-for-portable-native-client">Example of a <code>program</code> for Portable Native Client:</h4> <pre class="prettyprint"> { @@ -97,7 +92,6 @@ an <code>optlevel</code> to best balance load time and application performance.< for debugging. The <code>url</code> provided in this section will be used when Native Client debugging is enabled with either the <code>--enable-nacl-debug</code> Chrome command line switch, or via <code>about://flags</code>.</p> -</section><section id="example-of-a-program-for-statically-linked-native-client-executables"> <h4 id="example-of-a-program-for-statically-linked-native-client-executables">Example of a <code>program</code> for statically linked Native Client executables</h4> <pre class="prettyprint"> { @@ -110,7 +104,6 @@ command line switch, or via <code>about://flags</code>.</p> } } </pre> -</section><section id="example-of-a-program-for-dynamically-linked-native-client-executables"> <h4 id="example-of-a-program-for-dynamically-linked-native-client-executables">Example of a <code>program</code> for dynamically linked Native Client executables</h4> <pre class="prettyprint"> { @@ -130,7 +123,6 @@ command line switch, or via <code>about://flags</code>.</p> } } </pre> -</section></section><section id="files"> <h3 id="files">files</h3> <p>The <code>files</code> field specifies a dictionary of file resources to be used by a Native Client application. This is not supported and not needed by Portable @@ -193,9 +185,7 @@ file systems and memory-based file systems. The Native Client SDK includes helpful tools for determining library dependencies and generating NaCl manifest files for programs that that use dynamic linking. See <a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html#dynamic-loading-manifest"><em>Generating a Native Client manifest file for a dynamically linked application</em></a>.</p> -</section></section><section id="semantics"> <h2 id="semantics">Semantics</h2> -<section id="schema-validation"> <h3 id="schema-validation">Schema validation</h3> <p>Manifests are validated before the program files are downloaded. Schema validation checks the following properties:</p> @@ -209,7 +199,6 @@ in “program” and in every entry within “files”.</li> <p>If the manifest contains a field that is not in the official set of supported fields, it is ignored. This allows the grammar to be extended without breaking compatibility with older browsers.</p> -</section><section id="nexe-matching"> <h3 id="nexe-matching">Nexe matching</h3> <p>For Portable Native Client, there are no architecture variations, so matching is simple.</p> @@ -217,7 +206,6 @@ matching is simple.</p> looking up the browser’s current architecture in the <code>"program"</code> dictionary. Failure to provide an entry for the browser’s architecture will result in a load error.</p> -</section><section id="file-matching"> <h3 id="file-matching">File matching</h3> <p>All files (shared objects and other assets, typically) are looked up by a UTF8 string that is the file name. To load a library with a certain @@ -231,7 +219,6 @@ non-architecture-specific asset files. Note that <code>"files"</code> useful for files that must be loaded early in application startup (before PPAPI interfaces are initialized to provide the standard file loading mechanisms).</p> -</section><section id="url-of-the-nmf-file-from-embed-src-and-data-uri"> <h3 id="url-of-the-nmf-file-from-embed-src-and-data-uri">URL of the nmf file, from <code><embed></code> src, and data URI</h3> <p>The URL for the manifest file should be specified by the <code>src</code> attribute of the <code><embed></code> tag for a Native Client module instance. The URL for @@ -240,11 +227,10 @@ a manifest file can refer to an actual file, or it can be a representing the contents of the file. Specifying the <code>nmf</code> contents inline with a data URI can help reduce the amount of network traffic required to load the Native Client application.</p> -</section><section id="url-resolution"> -<span id="nmf-url-resolution"></span><h3 id="url-resolution"><span id="nmf-url-resolution"></span>URL resolution</h3> +<h3 id="url-resolution"><span id="nmf-url-resolution"></span>URL resolution</h3> <p>All URLs contained in a manifest are resolved relative to the URL of the manifest. If the manifest was specified as a data URI, the URLs must all be absolute.</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/pnacl-bitcode-abi.html b/native_client_sdk/doc_generated/reference/pnacl-bitcode-abi.html index f6c2590631..1259c79ad6 100644 --- a/native_client_sdk/doc_generated/reference/pnacl-bitcode-abi.html +++ b/native_client_sdk/doc_generated/reference/pnacl-bitcode-abi.html @@ -54,8 +54,7 @@ </li> </ul> -</div><section id="introduction"> -<h2 id="introduction">Introduction</h2> +</div><h2 id="introduction">Introduction</h2> <p>This document is a reference manual for the PNaCl bitcode format. It describes the bitcode on a <em>semantic</em> level; the physical encoding level will be described elsewhere. For the purpose of this document, the textual form of LLVM IR is @@ -65,10 +64,8 @@ version 3.3, many sections in this document point to a relevant section of the LLVM language reference manual. Only the changes, restrictions and variations specific to PNaCl are described—full semantic descriptions are not duplicated from the LLVM reference manual.</p> -</section><section id="high-level-structure"> <h2 id="high-level-structure">High Level Structure</h2> <p>A PNaCl portable executable (<strong>pexe</strong> in short) is a single LLVM IR module.</p> -<section id="data-model"> <h3 id="data-model">Data Model</h3> <p>The data model for PNaCl bitcode is fixed at little-endian ILP32: pointers are 32 bits in size. 64-bit integer types are also supported natively via the i64 @@ -76,24 +73,20 @@ type (for example, a front-end can generate these from the C/C++ type <code>long long</code>).</p> <p>Floating point support is fixed at IEEE 754 32-bit and 64-bit values (f32 and f64, respectively).</p> -</section><section id="linkage-types"> -<span id="bitcode-linkagetypes"></span><h3 id="linkage-types"><span id="bitcode-linkagetypes"></span>Linkage Types</h3> +<h3 id="linkage-types"><span id="bitcode-linkagetypes"></span>Linkage Types</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#linkage">LLVM LangRef: Linkage Types</a></p> <p>The linkage types supported by PNaCl bitcode are <code>internal</code> and <code>external</code>. A single function in the pexe, named <code>_start</code>, has the linkage type <code>external</code>. All the other functions and globals have the linkage type <code>internal</code>.</p> -</section><section id="calling-conventions"> <h3 id="calling-conventions">Calling Conventions</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#callingconv">LLVM LangRef: Calling Conventions</a></p> <p>The only calling convention supported by PNaCl bitcode is <code>ccc</code> - the C calling convention.</p> -</section><section id="visibility-styles"> <h3 id="visibility-styles">Visibility Styles</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#visibility-styles">LLVM LangRef: Visibility Styles</a></p> <p>PNaCl bitcode does not support visibility styles.</p> -</section><section id="global-variables"> -<span id="bitcode-globalvariables"></span><h3 id="global-variables"><span id="bitcode-globalvariables"></span>Global Variables</h3> +<h3 id="global-variables"><span id="bitcode-globalvariables"></span>Global Variables</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#globalvars">LLVM LangRef: Global Variables</a></p> <p>Restrictions on global variables:</p> <ul class="small-gap"> @@ -124,7 +117,6 @@ negative):</li> </pre> <p>A <em>CompoundElement</em> is a unnamed, packed struct containing more than one <em>SimpleElement</em>.</p> -</section><section id="functions"> <h3 id="functions">Functions</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#functionstructure">LLVM LangRef: Functions</a></p> <p>The restrictions on <a class="reference internal" href="#bitcode-linkagetypes"><em>linkage types</em></a>, calling @@ -137,41 +129,33 @@ return type).</li> <li>Functions with a variable number of arguments (<em>vararg</em>).</li> <li>Alignment (<code>align</code>).</li> </ul> -</section><section id="aliases"> <h3 id="aliases">Aliases</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#aliases">LLVM LangRef: Aliases</a></p> <p>PNaCl bitcode does not support aliases.</p> -</section><section id="named-metadata"> <h3 id="named-metadata">Named Metadata</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#namedmetadatastructure">LLVM LangRef: Named Metadata</a></p> <p>While PNaCl bitcode has provisions for debugging metadata, it is not considered part of the stable ABI. It exists for tool support and should not appear in distributed pexes.</p> <p>Other kinds of LLVM metadata are not supported.</p> -</section><section id="module-level-inline-assembly"> <h3 id="module-level-inline-assembly">Module-Level Inline Assembly</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#moduleasm">LLVM LangRef: Module-Level Inline Assembly</a></p> <p>PNaCl bitcode does not support inline assembly.</p> -</section><section id="volatile-memory-accesses"> <h3 id="volatile-memory-accesses">Volatile Memory Accesses</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#volatile">LLVM LangRef: Volatile Memory Accesses</a></p> <p>PNaCl bitcode does not support volatile memory accesses. The <code>volatile</code> attribute on loads and stores is not supported. See the <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html"><em>PNaCl C/C++ Language Support</em></a> for more details.</p> -</section><section id="memory-model-for-concurrent-operations"> <h3 id="memory-model-for-concurrent-operations">Memory Model for Concurrent Operations</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#memmodel">LLVM LangRef: Memory Model for Concurrent Operations</a></p> <p>See the <a class="reference external" href="PNaClDeveloperGuide.html">PNaCl Developer’s Guide</a> for more details.</p> -</section><section id="fast-math-flags"> <h3 id="fast-math-flags">Fast-Math Flags</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#fastmath">LLVM LangRef: Fast-Math Flags</a></p> <p>Fast-math mode is not currently supported by the PNaCl bitcode.</p> -</section></section><section id="type-system"> <h2 id="type-system">Type System</h2> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#typesystem">LLVM LangRef: Type System</a></p> <p>The LLVM types allowed in PNaCl bitcode are restricted, as follows:</p> -<section id="scalar-types"> <h3 id="scalar-types">Scalar types</h3> <ul class="small-gap"> <li><p class="first">The only scalar types allowed are integer, float (32-bit floating point), @@ -183,7 +167,6 @@ values are i32 and i64.</li> </ul> </li> </ul> -</section><section id="vector-types"> <h3 id="vector-types">Vector types</h3> <p>The only vector types allowed are:</p> <ul class="small-gap"> @@ -193,12 +176,10 @@ values are i32 and i64.</li> element counts listed previously (their width is therefore not 128-bits).</li> </ul> -</section><section id="array-and-struct-types"> <h3 id="array-and-struct-types">Array and struct types</h3> <p>Array and struct types are only allowed in <a class="reference internal" href="#bitcode-globalvariables"><em>global variable initializers</em></a>.</p> -</section><section id="pointer-types"> -<span id="bitcode-pointertypes"></span><h3 id="pointer-types"><span id="bitcode-pointertypes"></span>Pointer types</h3> +<h3 id="pointer-types"><span id="bitcode-pointertypes"></span>Pointer types</h3> <p>Only the following pointer types are allowed:</p> <ul class="small-gap"> <li>Pointers to valid PNaCl bitcode scalar types, as specified above, except for @@ -216,38 +197,30 @@ instruction, or is an address of a global value.</p> <li>Is the return value of a <code>bitcast</code> instruction.</li> <li>Is the return value of a <code>inttoptr</code> instruction.</li> </ul> -</section><section id="undefined-values"> <h3 id="undefined-values">Undefined Values</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#undefvalues">LLVM LangRef: Undefined Values</a></p> <p><code>undef</code> is only allowed within functions, not in global variable initializers.</p> -</section><section id="constant-expressions"> <h3 id="constant-expressions">Constant Expressions</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#constant-expressions">LLVM LangRef: Constant Expressions</a></p> <p>Constant expressions are only allowed in <a class="reference internal" href="#bitcode-globalvariables"><em>global variable initializers</em></a>.</p> -</section></section><section id="other-values"> <h2 id="other-values">Other Values</h2> -<section id="metadata-nodes-and-metadata-strings"> <h3 id="metadata-nodes-and-metadata-strings">Metadata Nodes and Metadata Strings</h3> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#metadata">LLVM LangRef: Metadata Nodes and Metadata Strings</a></p> <p>While PNaCl bitcode has provisions for debugging metadata, it is not considered part of the stable ABI. It exists for tool support and should not appear in distributed pexes.</p> <p>Other kinds of LLVM metadata are not supported.</p> -</section></section><section id="intrinsic-global-variables"> <h2 id="intrinsic-global-variables">Intrinsic Global Variables</h2> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#intrinsic-global-variables">LLVM LangRef: Intrinsic Global Variables</a></p> <p>PNaCl bitcode does not support intrinsic global variables.</p> -</section><section id="errno-and-errors-in-arithmetic-instructions"> -<span id="ir-and-errno"></span><h2 id="errno-and-errors-in-arithmetic-instructions"><span id="ir-and-errno"></span>Errno and errors in arithmetic instructions</h2> +<h2 id="errno-and-errors-in-arithmetic-instructions"><span id="ir-and-errno"></span>Errno and errors in arithmetic instructions</h2> <p>Some arithmetic instructions and intrinsics have the similar semantics to libc math functions, but differ in the treatment of <code>errno</code>. While the libc functions may set <code>errno</code> for domain errors, the instructions and intrinsics do not. This is because the variable <code>errno</code> is not special and is not required to be part of the program.</p> -</section><section id="instruction-reference"> <h2 id="instruction-reference">Instruction Reference</h2> -<section id="list-of-allowed-instructions"> <h3 id="list-of-allowed-instructions">List of allowed instructions</h3> <p>This is a list of LLVM instructions supported by PNaCl bitcode. Where applicable, PNaCl-specific restrictions are provided.</p> @@ -331,17 +304,14 @@ argument must be an i32.</p> <li><code>insertelement</code></li> <li><code>extractelement</code></li> </ul> -</section><section id="alloca"> -<span id="bitcode-allocainst"></span><h3 id="alloca"><span id="bitcode-allocainst"></span><code>alloca</code></h3> +<h3 id="alloca"><span id="bitcode-allocainst"></span><code>alloca</code></h3> <p>The only allowed type for <code>alloca</code> instructions in PNaCl bitcode is i8. The size argument must be an i32. For example:</p> <pre> %buf = alloca i8, i32 8, align 4 </pre> -</section></section><section id="intrinsic-functions"> <h2 id="intrinsic-functions">Intrinsic Functions</h2> <p><a class="reference external" href="http://llvm.org/releases/3.3/docs/LangRef.html#intrinsics">LLVM LangRef: Intrinsic Functions</a></p> -<section id="list-of-allowed-intrinsics"> <h3 id="list-of-allowed-intrinsics">List of allowed intrinsics</h3> <p>The only intrinsics supported by PNaCl bitcode are the following.</p> <ul class="small-gap"> @@ -397,15 +367,13 @@ execution.</p> <p>See <a class="reference internal" href="#bitcode-atomicintrinsics"><em>atomic intrinsics</em></a>.</p> </li> </ul> -</section><section id="thread-pointer-related-intrinsics"> -<span id="bitcode-threadpointerintrinsics"></span><h3 id="thread-pointer-related-intrinsics"><span id="bitcode-threadpointerintrinsics"></span>Thread pointer related intrinsics</h3> +<h3 id="thread-pointer-related-intrinsics"><span id="bitcode-threadpointerintrinsics"></span>Thread pointer related intrinsics</h3> <pre> declare i8* @llvm.nacl.read.tp() </pre> <p>Returns a read-only thread pointer. The value is controlled by the embedding sandbox’s runtime.</p> -</section><section id="setjmp-and-longjmp"> -<span id="bitcode-setjmplongjmp"></span><h3 id="setjmp-and-longjmp"><span id="bitcode-setjmplongjmp"></span>Setjmp and Longjmp</h3> +<h3 id="setjmp-and-longjmp"><span id="bitcode-setjmplongjmp"></span>Setjmp and Longjmp</h3> <pre> declare void @llvm.nacl.longjmp(i8* %jmpbuf, i32) declare i32 @llvm.nacl.setjmp(i8* %jmpbuf) @@ -413,8 +381,7 @@ sandbox’s runtime.</p> <p>These intrinsics implement the semantics of C11 <code>setjmp</code> and <code>longjmp</code>. The <code>jmpbuf</code> pointer must be 64-bit aligned and point to at least 1024 bytes of allocated memory.</p> -</section><section id="atomic-intrinsics"> -<span id="bitcode-atomicintrinsics"></span><h3 id="atomic-intrinsics"><span id="bitcode-atomicintrinsics"></span>Atomic intrinsics</h3> +<h3 id="atomic-intrinsics"><span id="bitcode-atomicintrinsics"></span>Atomic intrinsics</h3> <pre> declare iN @llvm.nacl.atomic.load.<size>( iN* <source>, i32 <memory_order>) @@ -473,6 +440,6 @@ are lock-free or not. This reflects the C11 <code>atomic_is_lock_free</code> function from header <code><stdatomic.h></code> and the C++11 <code>is_lock_free</code> member function in header <code><atomic></code>. It can be used through the <code>__nacl_atomic_is_lock_free</code> builtin.</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/pnacl-c-cpp-language-support.html b/native_client_sdk/doc_generated/reference/pnacl-c-cpp-language-support.html index 7ee087ee66..bc665e2be1 100644 --- a/native_client_sdk/doc_generated/reference/pnacl-c-cpp-language-support.html +++ b/native_client_sdk/doc_generated/reference/pnacl-c-cpp-language-support.html @@ -38,8 +38,7 @@ </li> </ul> -</div><section id="source-language-support"> -<h2 id="source-language-support">Source language support</h2> +</div><h2 id="source-language-support">Source language support</h2> <p>The currently supported languages are C and C++. The PNaCl toolchain is based on recent Clang, which fully supports C++11 and most of C11. A detailed status of the language support is available <a class="reference external" href="http://clang.llvm.org/cxx_status.html">here</a>.</p> @@ -49,7 +48,6 @@ section on other languages</em></a>.</p> <code>libc++</code>, and the <code>newlib</code> standard C library. <code>libstdc++</code> is also supported but its use is discouraged; see <a class="reference internal" href="/native-client/devguide/devcycle/building.html#building-cpp-libraries"><em>C++ standard libraries</em></a> for more details.</p> -<section id="versions"> <h3 id="versions">Versions</h3> <p>Version information can be obtained:</p> <ul class="small-gap"> @@ -58,14 +56,11 @@ for more details.</p> <li><code>libc++</code>: use the <code>_LIBCPP_VERSION</code> macro.</li> <li><code>libstdc++</code>: use the <code>_GLIBCXX_VERSION</code> macro.</li> </ul> -</section><section id="preprocessor-definitions"> <h3 id="preprocessor-definitions">Preprocessor definitions</h3> <p>When compiling C/C++ code, the PNaCl toolchain defines the <code>__pnacl__</code> macro. In addition, <code>__native_client__</code> is defined for compatibility with other NaCl toolchains.</p> -</section></section><section id="memory-model-and-atomics"> -<span id="id1"></span><h2 id="memory-model-and-atomics"><span id="id1"></span>Memory Model and Atomics</h2> -<section id="memory-model-for-concurrent-operations"> +<h2 id="memory-model-and-atomics"><span id="id1"></span>Memory Model and Atomics</h2> <h3 id="memory-model-for-concurrent-operations">Memory Model for Concurrent Operations</h3> <p>The memory model offered by PNaCl relies on the same coding guidelines as the C11/C++11 one: concurrent accesses must always occur through @@ -112,7 +107,6 @@ to indirectly access devices.</li> <p>Setting up the above mechanisms requires assistance from the embedding sandbox’s runtime (e.g. NaCl’s Pepper APIs), but using them once setup can be done through regular C/C++ code.</p> -</section><section id="atomic-memory-ordering-constraints"> <h3 id="atomic-memory-ordering-constraints">Atomic Memory Ordering Constraints</h3> <p>Atomics follow the same ordering constraints as in regular C11/C++11, but all accesses are promoted to sequential consistency (the strongest @@ -128,7 +122,6 @@ primitives, and these primitives must always be of the same bit size for that location.</li> <li>Not all memory orderings are valid for all atomic operations.</li> </ul> -</section><section id="volatile-memory-accesses"> <h3 id="volatile-memory-accesses">Volatile Memory Accesses</h3> <p>The C11/C++11 standards mandate that <code>volatile</code> accesses execute in program order (but are not fences, so other memory operations can @@ -153,18 +146,15 @@ naturally aligned, and tries to guarantee this alignment.</p> code, and combined with builtin fences these programs can do meaningful cross-thread communication without changing code. They also better reflect the original code’s intent and guarantee better portability.</p> -</section></section><section id="threading"> -<span id="language-support-threading"></span><h2 id="threading"><span id="language-support-threading"></span>Threading</h2> +<h2 id="threading"><span id="language-support-threading"></span>Threading</h2> <p>Threading is explicitly supported through C11/C++11’s threading libraries as well as POSIX threads.</p> <p>Communication between threads should use atomic primitives as described in <a class="reference internal" href="#id1">Memory Model and Atomics</a>.</p> -</section><section id="setjmp-and-longjmp"> <h2 id="setjmp-and-longjmp"><code>setjmp</code> and <code>longjmp</code></h2> <p>PNaCl and NaCl support <code>setjmp</code> and <code>longjmp</code> without any restrictions beyond C’s.</p> -</section><section id="c-exception-handling"> -<span id="exception-handling"></span><h2 id="c-exception-handling"><span id="exception-handling"></span>C++ Exception Handling</h2> +<h2 id="c-exception-handling"><span id="exception-handling"></span>C++ Exception Handling</h2> <p>PNaCl currently supports C++ exception handling through <code>setjmp()</code> and <code>longjmp()</code>, which can be enabled with the <code>--pnacl-exceptions=sjlj</code> linker flag. Exceptions are disabled by default so that faster and @@ -173,7 +163,6 @@ calls to <code>abort()</code>. The usual <code>-fno-exceptions</code> flag is al supported. PNaCl will support full zero-cost exception handling in the future.</p> <p>NaCl supports full zero-cost C++ exception handling.</p> -</section><section id="inline-assembly"> <h2 id="inline-assembly">Inline Assembly</h2> <p>Inline assembly isn’t supported by PNaCl because it isn’t portable. The one current exception is the common compiler barrier idiom @@ -188,17 +177,16 @@ inline assembly.</p> <p>NaCl supports a fairly wide subset of inline assembly through GCC’s inline assembly syntax, with the restriction that the sandboxing model for the target architecture has to be respected.</p> -</section><section id="portable-simd-vectors"> -<span id="id2"></span><h2 id="portable-simd-vectors"><span id="id2"></span>Portable SIMD Vectors</h2> +<h2 id="portable-simd-vectors"><span id="id2"></span>Portable SIMD Vectors</h2> <p>SIMD vectors aren’t part of the C/C++ standards and are traditionally very hardware-specific. Portable Native Client offers a portable version of SIMD vector datatypes and operations which map well to modern architectures and offer performance which matches or approaches hardware-specific uses.</p> -<p>SIMD vector support was added to Portable Native Client for version 37 -of Chrome and more features, including performance enhancements, are -expected to be added in subsequent releases.</p> -<section id="hand-coding-vector-extensions"> +<p>SIMD vector support was added to Portable Native Client for version 37 of Chrome +and more features, including performance enhancements, have been added in +subsequent releases, see the <a class="reference internal" href="/native-client/sdk/release-notes.html#sdk-release-notes"><em>Release Notes</em></a> for more +details.</p> <h3 id="hand-coding-vector-extensions">Hand-Coding Vector Extensions</h3> <p>The initial vector support in Portable Native Client adds <a class="reference external" href="http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors">LLVM vectors</a> and <a class="reference external" href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html">GCC vectors</a> since these @@ -225,8 +213,10 @@ v4s snip(v4s in) { return ret; } </pre> -<p>Vector datatypes are currently expected to be 128-bit wide with one of -the following element types:</p> +<p>Vector datatypes are currently expected to be 128-bit wide with one of the +following element types, and they’re expected to be aligned to the underlying +element’s bit width (loads and store will otherwise be broken up into scalar +accesses to prevent faults):</p> <table border="1" class="docutils"> <colgroup> </colgroup> @@ -234,41 +224,56 @@ the following element types:</p> <tr class="row-odd"><th class="head">Type</th> <th class="head">Num Elements</th> <th class="head">Vector Bit Width</th> +<th class="head">Expected Bit Alignment</th> </tr> </thead> <tbody valign="top"> <tr class="row-even"><td><code>uint8_t</code></td> <td>16</td> <td>128</td> +<td>8</td> </tr> <tr class="row-odd"><td><code>int8_t</code></td> <td>16</td> <td>128</td> +<td>8</td> </tr> <tr class="row-even"><td><code>uint16_t</code></td> <td>8</td> <td>128</td> +<td>16</td> </tr> <tr class="row-odd"><td><code>int16_t</code></td> <td>8</td> <td>128</td> +<td>16</td> </tr> <tr class="row-even"><td><code>uint32_t</code></td> <td>4</td> <td>128</td> +<td>32</td> </tr> <tr class="row-odd"><td><code>int32_t</code></td> <td>4</td> <td>128</td> +<td>32</td> </tr> <tr class="row-even"><td><code>float</code></td> <td>4</td> <td>128</td> +<td>32</td> </tr> </tbody> </table> <p>64-bit integers and double-precision floating point will be supported in a future release, as will 256-bit and 512-bit vectors.</p> +<p>Vector element bit width alignment can be stated explicitly (this is assumed by +PNaCl, but not necessarily by other compilers), and smaller alignments can also +be specified:</p> +<pre class="prettyprint"> +typedef int v4s_element __attribute__((vector_size(16), aligned(4))); +typedef int v4s_unaligned __attribute__((vector_size(16), aligned(1))); +</pre> <p>The following operators are supported on vectors:</p> <table border="1" class="docutils"> <colgroup> @@ -357,15 +362,12 @@ v4s shift_right_by(v4s shift_me, int shift_amount) { return shift_me >> __builtin_shuffle_vector(tmp, tmp, 0, 0, 0, 0); } </pre> -</section><section id="auto-vectorization"> <h3 id="auto-vectorization">Auto-Vectorization</h3> <p>Auto-vectorization is currently not enabled for Portable Native Client, but will be in a future release.</p> -</section></section><section id="undefined-behavior"> <h2 id="undefined-behavior">Undefined Behavior</h2> <p>The C and C++ languages expose some undefined behavior which is discussed in <a class="reference internal" href="/native-client/reference/pnacl-undefined-behavior.html#undefined-behavior"><em>PNaCl Undefined Behavior</em></a>.</p> -</section><section id="floating-point"> <h2 id="floating-point">Floating-Point</h2> <p>PNaCl exposes 32-bit and 64-bit floating point operations which are mostly IEEE-754 compliant. There are a few caveats:</p> @@ -395,7 +397,6 @@ in the <em>pexe</em>.</li> </ul> </li> </ul> -</section><section id="computed-goto"> <h2 id="computed-goto">Computed <code>goto</code></h2> <p>PNaCl supports computed <code>goto</code>, a non-standard GCC extension to C used by some interpreters, by lowering them to <code>switch</code> statements. The @@ -405,16 +406,13 @@ compile-time option for using computed <code>goto</code>, it’s possible th program will run faster with the option turned off (e.g., if the program does extra work to take advantage of computed <code>goto</code>).</p> <p>NaCl supports computed <code>goto</code> without any transformation.</p> -</section><section id="future-directions"> <h2 id="future-directions">Future Directions</h2> -<section id="inter-process-communication"> <h3 id="inter-process-communication">Inter-Process Communication</h3> <p>Inter-process communication through shared memory is currently not supported by PNaCl/NaCl. When implemented, it may be limited to operations which are lock-free on the current platform (<code>is_lock_free</code> methods). It will rely on the address-free properly discussed in <a class="reference internal" href="#memory-model-for-concurrent-operations">Memory Model for Concurrent Operations</a>.</p> -</section><section id="posix-style-signal-handling"> <h3 id="posix-style-signal-handling">POSIX-style Signal Handling</h3> <p>POSIX-style signal handling really consists of two different features:</p> <ul class="small-gap"> @@ -438,6 +436,6 @@ or suspension of threads.</p> <p>If PNaCl were to support either of these, the interaction of <code>volatile</code> and atomics with same-thread signal handling would need to be carefully detailed.</p> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/pnacl-undefined-behavior.html b/native_client_sdk/doc_generated/reference/pnacl-undefined-behavior.html index 272b4a7bfb..d584d676df 100644 --- a/native_client_sdk/doc_generated/reference/pnacl-undefined-behavior.html +++ b/native_client_sdk/doc_generated/reference/pnacl-undefined-behavior.html @@ -21,8 +21,7 @@ </li> </ul> -</div><section id="overview"> -<span id="undefined-behavior"></span><h2 id="overview"><span id="undefined-behavior"></span>Overview</h2> +</div><h2 id="overview"><span id="undefined-behavior"></span>Overview</h2> <p>C and C++ undefined behavior allows efficient mapping of the source language onto hardware, but leads to different behavior on different platforms.</p> @@ -57,7 +56,6 @@ randomizations.</li> </ul> </li> </ul> -</section><section id="specification"> <h2 id="specification">Specification</h2> <p>PNaCl’s goal is that a single <em>pexe</em> should work reliably in the same manner on all architectures, irrespective of runtime parameters and @@ -72,9 +70,7 @@ and diverging behavior would be rare.</p> <p>Note that none of these issues are vulnerabilities in PNaCl and Chrome: the NaCl sandboxing still constrains the code through Software Fault Isolation.</p> -</section><section id="behavior-in-pnacl-bitcode"> <h2 id="behavior-in-pnacl-bitcode">Behavior in PNaCl Bitcode</h2> -<section id="well-defined"> <h3 id="well-defined">Well-Defined</h3> <p>The following are traditionally undefined behavior in C/C++ but are well defined at the <em>pexe</em> level:</p> @@ -103,12 +99,10 @@ Atomics</em></a>).</li> x86, and through integer divide emulation routine or explicit checks on ARM).</li> </ul> -</section><section id="not-well-defined"> <h3 id="not-well-defined">Not Well-Defined</h3> <p>The following are traditionally undefined behavior in C/C++ which also exhibit undefined behavior at the <em>pexe</em> level. Some are easier to fix than others.</p> -<section id="potentially-fixable"> <h4 id="potentially-fixable">Potentially Fixable</h4> <ul class="small-gap"> <li><p class="first">Shift by greater-than-or-equal to left-hand-side’s bit-width or @@ -155,8 +149,7 @@ will be undefined. PNaCl could change this to always trap, as the defined behavior. PNaCl’s frontend or the translator could insert checks with <code>-fsanitize=vla-bound</code>.</li> </ul> -</section><section id="floating-point"> -<span id="undefined-behavior-fp"></span><h4 id="floating-point"><span id="undefined-behavior-fp"></span>Floating-Point</h4> +<h4 id="floating-point"><span id="undefined-behavior-fp"></span>Floating-Point</h4> <p>PNaCl offers a IEEE-754 implementation which is as correct as the underlying hardware allows, with a few limitations. These are a few sources of undefined behavior which are believed to be fixable:</p> @@ -175,7 +168,6 @@ SIMD operations.</li> function implementation isn’t, e.g. <code>std::min</code> and <code>std::max</code>), is well-defined in the <em>pexe</em>.</li> </ul> -</section><section id="simd-vectors"> <h4 id="simd-vectors">SIMD Vectors</h4> <p>SIMD vector instructions aren’t part of the C/C++ standards and as such their behavior isn’t specified at all in C/C++; it is usually left up to @@ -185,7 +177,6 @@ offers the same guarantees on these vectors as the guarantees offered by the contained elements. Of notable interest amongst these guarantees are those of alignment for load/store instructions on vectors: they have the same alignment restriction as the contained elements.</p> -</section><section id="hard-to-fix"> <h4 id="hard-to-fix">Hard to Fix</h4> <ul class="small-gap"> <li><p class="first">Null pointer/reference has behavior determined by the NaCl sandbox:</p> @@ -231,6 +222,6 @@ and at least one of which is not atomic: this will be very dependent on processor and execution sequence, see <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#memory-model-and-atomics"><em>Memory Model and Atomics</em></a>.</li> </ul> -</section></section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/sandbox_internals/arm-32-bit-sandbox.html b/native_client_sdk/doc_generated/reference/sandbox_internals/arm-32-bit-sandbox.html index 32f8a84300..d55851fece 100644 --- a/native_client_sdk/doc_generated/reference/sandbox_internals/arm-32-bit-sandbox.html +++ b/native_client_sdk/doc_generated/reference/sandbox_internals/arm-32-bit-sandbox.html @@ -56,11 +56,9 @@ assembly languages in general.</p> </li> </ul> -</div><section id="an-introduction-to-the-arm-architecture"> -<h2 id="an-introduction-to-the-arm-architecture">An Introduction to the ARM Architecture</h2> +</div><h2 id="an-introduction-to-the-arm-architecture">An Introduction to the ARM Architecture</h2> <p>In this section, we summarize the relevant parts of the ARM processor architecture.</p> -<section id="about-arm-and-armv7-a"> <h3 id="about-arm-and-armv7-a">About ARM and ARMv7-A</h3> <p>ARM is one of the older commercial “RISC” processor designs, dating back to the early 1980s. Today, it is used primarily in embedded systems: @@ -81,7 +79,6 @@ also enhancing the 32-bit A32 ISA. For Native Client’s purposes the A32 ISA is equivalent to the ARMv7 ARM ISA, albeit with a few new instructions. This document only discussed the 32-bit A32 instruction set: A64 would require a different sandboxing model.</p> -</section><section id="arm-programmer-s-model"> <h3 id="arm-programmer-s-model">ARM Programmer’s Model</h3> <p>While modern ARM chips support several instruction encodings, 32-bit Native Client on ARM focuses on a single one: a fixed-width encoding @@ -129,7 +126,6 @@ pools”, just past the final return of a function.</li> </ol> <p>We’ll introduce more details of the ARM instruction set later, as we walk through the system.</p> -</section></section><section id="the-native-client-approach"> <h2 id="the-native-client-approach">The Native Client Approach</h2> <p>Native Client runs an untrusted program, potentially from an unknown or malicious source, inside a sandbox created by a trusted runtime. The @@ -175,7 +171,6 @@ system’s security.</p> For the computationally-inclined, all our validators scale linearly in the size of the program. </aside> -<section id="nacl-arm-pure-software-fault-isolation"> <h3 id="nacl-arm-pure-software-fault-isolation">NaCl/ARM: Pure Software Fault Isolation</h3> <p>In the original Native Client system for the x86, we used unusual hardware features of that processor (the segment registers) to isolate @@ -203,7 +198,6 @@ side effect, it helps to prevent programs from exploiting buggy operating system APIs.</p> <p>Let’s walk through the details, starting with the simplest part: <em>load</em> and <em>store</em>.</p> -<section id="load-and-store"> <h4 id="load-and-store"><em>Load</em> and <em>Store</em></h4> <p>All access to memory must be through <em>load</em> and <em>store</em> pseudo-instructions. These are simply a native <em>load</em> or <em>store</em> @@ -235,7 +229,6 @@ code.</p> program could set up carefully-crafted values in <code>rA</code>, and then jump straight to the <code>ldr</code>. This is why we validate that programs never split pseudo-instructions.</p> -<section id="alternative-sandboxing"> <h5 id="alternative-sandboxing">Alternative Sandboxing</h5> <pre> tst rA, #0xC0000000 @@ -269,7 +262,6 @@ be used for regular Native Client <strong>nexe</strong> files, but can be used w Portable Native Client because the target processor is known at translation time from <strong>pexe</strong> to <strong>nexe</strong>. </aside> -</section><section id="addressing-modes"> <h5 id="addressing-modes">Addressing Modes</h5> <p>ARM has an unusually rich set of addressing modes. We allow all but one: register-indexed, where two registers are added to determine the @@ -291,7 +283,6 @@ the largest immediate displacement is ±4095 bytes, while our guard pages are 8192 bytes wide.</p> <p>We also allow ARM’s more unusual <em>load</em> and <em>store</em> instructions, such as <em>load-multiple</em> and <em>store-multiple</em>, etc.</p> -</section><section id="conditional-load-and-store"> <h5 id="conditional-load-and-store">Conditional <em>Load</em> and <em>Store</em></h5> <p>There’s one problem with the pseudo-instructions shown above: they are unconditional (assuming <code>rA</code> is valid). ARM compilers regularly use @@ -303,9 +294,7 @@ pseudo-instructions. Here is a conditional <em>store</em> bicgt rA, #0xC0000000 strgt rX, [rA, #123] </pre> -</section></section><section id="the-stack-pointer-thread-pointer-and-program-counter"> <h4 id="the-stack-pointer-thread-pointer-and-program-counter">The Stack Pointer, Thread Pointer, and Program Counter</h4> -<section id="stack-pointer"> <h5 id="stack-pointer">Stack Pointer</h5> <p>In C-like languages, the stack is used to store return addresses during function calls, as well as any local variables that won’t fit in @@ -344,7 +333,6 @@ loop instead of using <code>sp</code> as a stack pointer it can be temporarily used as an index pointer (e.g. to traverse an array). This avoids the extra <code>bic</code> whenever the pointer is updated in the loop. </aside> -</section><section id="thread-pointer-loads"> <h5 id="thread-pointer-loads">Thread Pointer Loads</h5> <p>The thread pointer and IRT thread pointer are stored in the trusted address space. All uses and definitions of <code>r9</code> from untrusted code @@ -353,7 +341,6 @@ are forbidden except as follows:</p> ldr Rn, [r9] ; Load user thread pointer. ldr Rn, [r9, #4] ; Load IRT thread pointer. </pre> -</section><section id="pc-relative-loads"> <h5 id="pc-relative-loads"><code>pc</code>-relative Loads</h5> <p>By extension, we also allow <em>load</em> through the <code>pc</code> without a mask. The explanation is quite similar:</p> @@ -366,7 +353,6 @@ point into the sandbox.</li> <p>We do not allow <code>pc</code>-relative stores, because they look suspiciously like self-modifying code, or any addressing mode that would alter the <code>pc</code> as a side effect of the <em>load</em>.</p> -</section></section><section id="indirect-branch"> <h4 id="indirect-branch"><em>Indirect Branch</em></h4> <p>There are two types of control flow on ARM: direct and indirect. Direct control flow instructions have an embedded target address or @@ -384,7 +370,6 @@ exclusively through <code>bx</code> and <code>blx</code>. Because all of ARMR flow instructions are called <em>branch</em> instructions, we’ll use the term <em>indirect branch</em> from here on, even though this includes things like <em>virtual call</em>, <em>return</em>, and the like.</p> -<section id="the-trouble-with-indirection"> <h5 id="the-trouble-with-indirection">The Trouble with Indirection</h5> <p><em>Indirect branch</em> present two problems for Native Client:</p> <ul class="small-gap"> @@ -400,7 +385,6 @@ instructions are 32-bit wide. <p>Checking both of these for <em>direct branch</em> is easy: the validator just pulls the (fixed) target address out of the instruction and checks what it points to.</p> -</section><section id="the-native-client-solution-bundles"> <h5 id="the-native-client-solution-bundles">The Native Client Solution: “Bundles”</h5> <p>For <em>indirect branch</em>, we can address the first problem by simply masking some high-order bits off the address, like we did for <em>load</em> and @@ -472,7 +456,6 @@ impossible: by masking off the bottom 4 bits of the destination the interworking nature of ARM’s <em>indirect branch</em> is completely avoided.</p> </aside> -</section><section id="call-and-return"> <h5 id="call-and-return"><em>Call</em> and <em>Return</em></h5> <p>On ARM, there is no <em>call</em> or <em>return</em> instruction. A <em>call</em> is simply a <em>branch</em> that just happen to load a return address into <code>lr</code>, the link @@ -517,7 +500,6 @@ perform much better by allowing it to speculatively execute the return address’ code. For more information on ARM’s <em>call</em>/<em>return</em> stack see ARM’s technical reference manual. </aside> -</section></section><section id="literal-pools-and-data-bundles"> <h4 id="literal-pools-and-data-bundles">Literal Pools and Data Bundles</h4> <p>In the section where we described the ARM architecture, we mentioned ARM’s unusual immediate forms. To restate:</p> @@ -568,7 +550,6 @@ opposite problem: what if the program needs to contain a certain constant that just happens to encode a malicious instruction? We want to allow this, but we have to be certain it will never be executed as code!</p> -<section id="data-bundles-to-the-rescue"> <h5 id="data-bundles-to-the-rescue">Data Bundles to the Rescue</h5> <p>As we discussed in the last section, ARM code in Native Client is structured in 16-byte bundles. We allow literal pools by putting them in @@ -608,7 +589,6 @@ therefore doubles as a roadblock in T32, if anything were to go so awry that we tried to execute it as a T32 instruction! Much defense, such depth, wow! </aside> -</section></section></section><section id="trampolines-and-memory-layout"> <h3 id="trampolines-and-memory-layout">Trampolines and Memory Layout</h3> <p>So far, the rules we’ve described make for boring programs: they can’t communicate with the outside world!</p> @@ -633,7 +613,6 @@ address.</p> <p>The validator can detect attempts to use the trampolines because they’re loaded at a fixed location in memory. Let’s look at the memory map of the Native Client sandbox.</p> -<section id="memory-map"> <h4 id="memory-map">Memory Map</h4> <p>The ARM sandbox is always at virtual address <code>0</code>, and is exactly 1GiB in size. This includes the untrusted program’s code and data, the @@ -690,7 +669,6 @@ possibility of optional 32-byte bundles, to enable certain compiler improvements. While this option isn’t available to untrusted programs today, we’re trying to keep the system “32-byte clean”. </aside> -</section><section id="inside-a-trampoline"> <h4 id="inside-a-trampoline">Inside a Trampoline</h4> <p>When we introduced trampolines, we mentioned that they can do things that untrusted programs can’t. To be more specific, trampolines can jump @@ -714,9 +692,7 @@ because, in practice, all trampolines jump to the same routine in the trusted runtime, called the syscall hook. It uses the return address produced by the final <code>blx</code> instruction to determine which trampoline was called.</p> -</section></section><section id="loose-ends"> <h3 id="loose-ends">Loose Ends</h3> -<section id="forbidden-instructions"> <h4 id="forbidden-instructions">Forbidden Instructions</h4> <p>To complete the sandbox, the validator ensures that the program does not try to use certain forbidden instructions.</p> @@ -772,7 +748,6 @@ treated as suspicious.</li> <p>More details are available in the <a class="reference external" href="http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/armv7.table">ARMv7 instruction table definition</a>.</p> </aside> -</section><section id="coprocessors"> <h4 id="coprocessors">Coprocessors</h4> <p>ARM has traditionally added new instruction set features through coprocessors. Coprocessors are accessed through a small set of @@ -800,7 +775,6 @@ ability to model the operations on these coprocessors, given that vendors often leave them poorly-specified. Unfortunately this eliminates some legacy floating point and vector implementations, but these are superceded on ARMv7-A parts anyway.</p> -</section><section id="validator-code"> <h4 id="validator-code">Validator Code</h4> <p>By now you’re itching to see the sandbox validator’s code and dissect it. You’ll have a disapointing read: at less that 500 lines of code @@ -808,6 +782,6 @@ it. You’ll have a disapointing read: at less that 500 lines of code is quite simple to understand and much shorter than this document. It’s of course dependent on the <a class="reference external" href="http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/armv7.table">ARMv7 instruction table definition</a>, which teaches it about the ARMv7 instruction set.</p> -</section></section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/reference/sandbox_internals/x86-64-sandbox.html b/native_client_sdk/doc_generated/reference/sandbox_internals/x86-64-sandbox.html index 5dd6a662c3..b24d24e3bd 100644 --- a/native_client_sdk/doc_generated/reference/sandbox_internals/x86-64-sandbox.html +++ b/native_client_sdk/doc_generated/reference/sandbox_internals/x86-64-sandbox.html @@ -11,8 +11,7 @@ <li><a class="reference internal" href="#list-of-pseudo-instructions" id="id9">List of Pseudo-instructions</a></li> </ul> -</div><section id="summary"> -<h2 id="summary">Summary</h2> +</div><h2 id="summary">Summary</h2> <p>This document addresses the details of the Software Fault Isolation (SFI) model for executable code that can be run in Native Client on an x86-64 system. An overview of this model can be found in the paper: @@ -25,7 +24,6 @@ dependencies when possible.</p> <p>Please note: throughout this document we use the AT&T notation for assembler syntax, in which the target operand appears last, e.g. <code>mov src, dst</code>.</p> -</section><section id="binary-format"> <h2 id="binary-format">Binary Format</h2> <p>The format of Native Client executable binaries is identical to the x86-64 ELF binary format (<a class="reference external" href="http://en.wikipedia.org/wiki/Executable_and_Linkable_Format">[0]</a>, <a class="reference external" href="http://www.sco.com/developers/devspecs/gabi41.pdf">[1]</a>, <a class="reference external" href="http://www.sco.com/developers/gabi/latest/contents.html">[2]</a>, <a class="reference external" href="http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf">[3]</a>) for @@ -43,7 +41,6 @@ segment must follow <a class="reference internal" href="#x86-64-text-segment-rul <li>There can be at most one PT_GNU_STACK segment. It must be marked RW.</li> <li>All segments must end before limit address (4 GiB).</li> </ul> -</section><section id="runtime-invariants"> <h2 id="runtime-invariants">Runtime Invariants</h2> <p>To ensure fault isolation at runtime, the system must maintain a number of runtime <em>invariants</em> across the lifetime of the running @@ -86,8 +83,7 @@ aligned and fits within a single <em>bundle</em>.</li> <li>The OS must not put any internal structures/code into the untrusted region at any time (not using OS dynamic linker, etc)</li> </ul> -</section><section id="text-segment-rules"> -<span id="x86-64-text-segment-rules"></span><h2 id="text-segment-rules"><span id="x86-64-text-segment-rules"></span>Text Segment Rules</h2> +<h2 id="text-segment-rules"><span id="x86-64-text-segment-rules"></span>Text Segment Rules</h2> <ul class="small-gap"> <li>The validation process must ensure that the text segment complies with the following rules. The validation process must complete @@ -194,7 +190,6 @@ which must not cross <em>bundle</em> boundaries:</li> popq ... ; except pop %RSP, pop %RBP </pre> </div></blockquote> -</section><section id="list-of-pseudo-instructions"> <h2 id="list-of-pseudo-instructions">List of Pseudo-instructions</h2> <p>Pseudo-instructions were introduced to let the compiler maintain the invariants without needing to know the code alignment rules. The @@ -322,6 +317,6 @@ lea (%rZP,%rdi,1),%rdi<br/> </td> </tr> </tbody> -</table></section></section> +</table></section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/rest-devsite-examples.html b/native_client_sdk/doc_generated/rest-devsite-examples.html index 9f912685c3..cc3c6285fe 100644 --- a/native_client_sdk/doc_generated/rest-devsite-examples.html +++ b/native_client_sdk/doc_generated/rest-devsite-examples.html @@ -2,12 +2,10 @@ <section id="examples-of-rest-markup-for-chromesite-document-title"> <h1 id="examples-of-rest-markup-for-chromesite-document-title">Examples of ReST markup for chromesite (Document title)</h1> -<section id="document-structure"> <h2 id="document-structure">Document structure</h2> <p>A document starts with a Sphinx target which serves as the document name throughout the tree. It can serve as a link target in other documents that want to link to this one (see the Links section below).</p> -</section><section id="basic-markup"> <h2 id="basic-markup">Basic markup</h2> <p>In general, follow the rules from <a class="reference external" href="http://sphinx-doc.org/rest.html">http://sphinx-doc.org/rest.html</a></p> <p>Some <strong>bold text</strong> and <em>italic text</em> and <code>fixed-font text</code>. Non marked-up text @@ -20,23 +18,18 @@ wrap at 80 columns, no tabs, etc.</p> get adulation by the public, but because it is fun to program. – Linus Torvalds</div></blockquote> <p>Here’s an en-dash – and an m-dash — too.</p> -<section id="unicode-samples"> <h3 id="unicode-samples">Unicode samples</h3> <p>Copyright sign ©, and uacute Ú.</p> -</section></section><section id="images"> <h2 id="images">Images</h2> <p>Please use absolute paths (starting with <code>/</code>) for images:</p> <img alt="/native-client/images/NaclBlock.png" src="/native-client/images/NaclBlock.png" /> -</section><section id="links"> <h2 id="links">Links</h2> -<section id="to-other-documents-within-the-tree"> <h3 id="to-other-documents-within-the-tree">To other documents within the tree</h3> <p>Internal links to other documents are created <a class="reference internal" href="/native-client/overview.html"><em>like this</em></a>. The document name within the angle brackets is relative to the root dir of the doc tree and does not have an extension.</p> <p>Here’s a link to a document in a subdirectory: <a class="reference internal" href="/native-client/devguide/tutorial/tutorial-part1.html"><em>the tutorial</em></a>. And a link to a subdirectory index page <a class="reference internal" href="/native-client/devguide/index.html"><em>devguide index</em></a>.</p> -</section><section id="to-sections-inside-documents"> <h3 id="to-sections-inside-documents">To sections inside documents</h3> <p>To internal locations within documents, labels are used. For example, this link goes to the label explicitly placed in this document - @@ -44,10 +37,8 @@ goes to the label explicitly placed in this document - names must be unique in the tree, and can refer to anything (like images).</p> <p>It’s also possible to give such cross-references custom names: <a class="reference internal" href="#link-for-section-heading"><em>Same Section Heading</em></a>.</p> -</section><section id="to-external-locations"> <h3 id="to-external-locations">To external locations</h3> <p>Plain links can be placed like this: <a class="reference external" href="http://google.com">http://google.com</a> and also <a class="reference external" href="http://google.com">like this</a>.</p> -</section></section><section id="definition-lists"> <h2 id="definition-lists">Definition lists</h2> <p>Can be used to define a group of related terms. Internal formatting is supported within the definition. No special formatting needs to be done for the definition @@ -64,7 +55,6 @@ anjeer (Iran, Pakistan), and dumur (Bengali).</dd> <dd>The pear is any of several tree and shrub species of genus Pyrus, in the family Rosaceae.</dd> </dl> -</section><section id="notes-and-admonitions"> <h2 id="notes-and-admonitions">Notes and Admonitions</h2> <p>The documentation server supports special “notes” that are indented and have a background color. We’ll generate them with the <code>Note</code> directive, providing @@ -79,7 +69,6 @@ the class explicitly. The class is one of <code>note</code>, <code>caution</cod <aside class="caution"> Caution – you have been warned. </aside> -</section><section id="source-code"> <h2 id="source-code">Source code</h2> <p>Here’s source code that will be pretty-printed. It’s just a plain <code><pre></code> that presents pre-formatted code with coloring:</p> @@ -100,21 +89,16 @@ $ echo "hello world" <p>By default <code>:prettyprint:</code> is <code>1</code>.</p> <p>For short inline code, use fixed-formatting like <code>int x = 2;</code>. Note that this won’t get syntax-highlighted and may be line-wrapped, so keep it very short.</p> -</section><section id="section-heading"> -<span id="link-for-section-heading"></span><h2 id="section-heading"><span id="link-for-section-heading"></span>Section heading</h2> +<h2 id="section-heading"><span id="link-for-section-heading"></span>Section heading</h2> <p>Here’s a demonstration of heading nesting levels. This is a top-level section in the document. The document title is the first header and it’s delimited by hash signes (<code>#</code>) from above and below.</p> -<section id="subsection-heading"> <h3 id="subsection-heading">Subsection heading</h3> <p>Subsection.</p> -<section id="sub-subsection-heading"> <h4 id="sub-subsection-heading">Sub-subsection heading</h4> <p>That’s pretty deep...</p> -<section id="sub-sub-subsection-heading"> <h5 id="sub-sub-subsection-heading">Sub-sub-subsection heading</h5> <p>It’s probably not the best idea to go this far (renders to <code><h5></code>).</p> -</section></section></section></section><section id="lists"> <h2 id="lists">Lists</h2> <p>Auto-numbered ordered lists:</p> <ol class="arabic simple"> @@ -144,7 +128,6 @@ signes (<code>#</code>) from above and below.</p> </li> <li>Back to top level</li> </ul> -</section><section id="tables"> <h2 id="tables">Tables</h2> <p>The full scoop on tables is <a class="reference external" href="http://sphinx-doc.org/rest.html#tables">http://sphinx-doc.org/rest.html#tables</a> and the Docutils pages linked from it.</p> @@ -202,6 +185,6 @@ Docutils pages linked from it.</p> </tr> </tbody> </table> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/sdk/download.html b/native_client_sdk/doc_generated/sdk/download.html index 3fc3dee0be..9961ec9b64 100644 --- a/native_client_sdk/doc_generated/sdk/download.html +++ b/native_client_sdk/doc_generated/sdk/download.html @@ -6,7 +6,6 @@ Client Software Development Kit (SDK). This page provides an overview of the Native Client SDK, and instructions for how to download and install the SDK.</p> -<section id="overview"> <h2 id="overview">Overview</h2> <p>The Native Client SDK includes the following:</p> <dl class="docutils"> @@ -44,7 +43,6 @@ tasks such as validating Native Client modules and running modules from the command line.</dd> </dl> <p>Follow the steps below to download and install the Native Client SDK.</p> -</section><section id="prerequisites"> <h2 id="prerequisites">Prerequisites</h2> <ul class="small-gap"> <li><p class="first"><strong>Python:</strong> Make sure you have Python 2.6 or 2.7 installed, and that the @@ -75,7 +73,6 @@ If you’d rather not install Xcode, you can download and build an <code>make</code>. In order to build the command you may also need to download and install a copy of <a class="reference external" href="https://github.com/kennethreitz/osx-gcc-installer">gcc</a>.</li> </ul> -</section><section id="download-and-install-the-sdk"> <h2 id="download-and-install-the-sdk">Download and install the SDK</h2> <ol class="arabic"> <li><p class="first">Download the SDK update utility: <a class="reference external" href="http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip">nacl_sdk.zip</a>.</p> @@ -169,7 +166,6 @@ updated automatically (if necessary) whenever you run <code>naclsdk</code>.</p> <aside class="note"> The minimum SDK bundle that supports PNaCl is <code>pepper_31</code>. </aside> -</section><section id="staying-up-to-date-and-getting-new-versions-of-bundles"> <h2 id="staying-up-to-date-and-getting-new-versions-of-bundles">Staying up-to-date and getting new versions of bundles</h2> <ol class="arabic"> <li><p class="first">Run <code>naclsdk</code> with the “list” command again; this will show you the list of @@ -273,6 +269,6 @@ the <a class="reference internal" href="/native-client/overview.html"><em>Techni <li>If you’d rather dive into information about the toolchains, see <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building Native Client Modules</em></a>.</li> </ul> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/sdk/examples.html b/native_client_sdk/doc_generated/sdk/examples.html index f69be51930..e6a6272b24 100644 --- a/native_client_sdk/doc_generated/sdk/examples.html +++ b/native_client_sdk/doc_generated/sdk/examples.html @@ -6,7 +6,6 @@ Each example demonstrates one or two key Native Client programming concepts. After you’ve <a class="reference internal" href="/native-client/sdk/download.html"><em>downloaded the SDK</em></a>, follow the instructions on this page to build and run the examples.</p> -<section id="configure-the-google-chrome-browser"> <h2 id="configure-the-google-chrome-browser">Configure the Google Chrome Browser</h2> <ol class="arabic"> <li><p class="first">Your version of Chrome must be equal to or greater than the version of @@ -52,7 +51,6 @@ Chrome window.</p> </ul> </li> </ol> -</section><section id="build-the-sdk-examples"> <h2 id="build-the-sdk-examples">Build the SDK examples</h2> <p>Starting with the <code>pepper_24</code> bundle, the Makefile scripts for the SDK examples build multiple versions of the examples using all three SDK @@ -154,8 +152,7 @@ For information about Native Client manifest files, see the <a class="reference Overview</em></a>.</p> <p>For details on how to use <code>make</code>, see the <a class="reference external" href="http://www.gnu.org/software/make/manual/make.html">GNU ‘make’ Manual</a>. For details on how to use the SDK toolchain itself, see <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building Native Client Modules</em></a>.</p> -</section><section id="run-the-sdk-examples"> -<span id="id1"></span><h2 id="run-the-sdk-examples"><span id="id1"></span>Run the SDK examples</h2> +<h2 id="run-the-sdk-examples"><span id="id1"></span>Run the SDK examples</h2> <p>To run the SDK examples, you can use the <code>make run</code> command:</p> <pre class="prettyprint"> $ cd pepper_31/examples/api/core @@ -207,8 +204,7 @@ $ export CHROME_PATH=<Path to Google Chrome> <pre class="prettyprint"> $ make run TOOLCHAIN=pnacl CONFIG=Debug </pre> -</section><section id="run-the-sdk-examples-as-packaged-apps"> -<span id="run-sdk-examples-as-packaged"></span><h2 id="run-the-sdk-examples-as-packaged-apps"><span id="run-sdk-examples-as-packaged"></span>Run the SDK examples as packaged apps</h2> +<h2 id="run-the-sdk-examples-as-packaged-apps"><span id="run-sdk-examples-as-packaged"></span>Run the SDK examples as packaged apps</h2> <p>Each example can also be launched as a packaged app. For more information about using Native Client for packaged apps, see <a class="reference internal" href="/native-client/devguide/distributing.html#distributing-packaged"><em>Packaged application</em></a>. For general information about packaged apps, see the <a class="reference external" href="/apps/about_apps">Chrome apps documentation</a>.</p> @@ -220,8 +216,7 @@ $ make run_package </pre> <p>You can use <code>TOOLCHAIN</code> and <code>CONFIG</code> parameters as above to run with a different toolchain or configuration.</p> -</section><section id="debugging-the-sdk-examples"> -<span id="id2"></span><h2 id="debugging-the-sdk-examples"><span id="id2"></span>Debugging the SDK examples</h2> +<h2 id="debugging-the-sdk-examples"><span id="id2"></span>Debugging the SDK examples</h2> <p>The NaCl SDK uses <a class="reference external" href="https://www.gnu.org/software/gdb/">GDB</a> to debug Native Client code. The SDK includes a prebuilt version of GDB that is compatible with NaCl code. To use it, run the <code>make debug</code> command from an example directory:</p> @@ -246,6 +241,6 @@ Remote debugging using :4014 The most common commands you will use to debug are <code>continue</code>, <code>step</code>, <code>next</code>, <code>break</code> and <code>backtrace</code>. See <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html"><em>Debugging</em></a> for more information about debugging a Native Client application.</p> -</section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/sdk/release-notes.html b/native_client_sdk/doc_generated/sdk/release-notes.html index bf47bc0273..57b09e9fe2 100644 --- a/native_client_sdk/doc_generated/sdk/release-notes.html +++ b/native_client_sdk/doc_generated/sdk/release-notes.html @@ -2,15 +2,12 @@ <section id="release-notes"> <span id="sdk-release-notes"></span><h1 id="release-notes"><span id="sdk-release-notes"></span>Release Notes</h1> -<section id="chrome-pepper-37-20-june-2014"> <h2 id="chrome-pepper-37-20-june-2014">Chrome/Pepper 37 (20 June 2014)</h2> -<section id="pnacl"> <h3 id="pnacl">PNaCl</h3> <ul class="small-gap"> <li>2–10% translation time improvement.</li> <li>Improved vector load/store and shuffle performance.</li> </ul> -</section><section id="pepper"> <h3 id="pepper">Pepper</h3> <ul class="small-gap"> <li>Media Streams Input support.</li> @@ -18,14 +15,11 @@ <li>Hardware Decode API in development preview.</li> <li>Sync API in development preview.</li> </ul> -</section><section id="sdk"> <h3 id="sdk">SDK</h3> <ul class="small-gap"> <li>Demo of a <a class="reference internal" href="/native-client/io2014.html#io2014"><em>full development environment in the browser</em></a>.</li> </ul> -</section></section><section id="chrome-pepper-36-09-may-2014"> <h2 id="chrome-pepper-36-09-may-2014">Chrome/Pepper 36 (09 May 2014)</h2> -<section id="id1"> <h3 id="id1">PNaCl</h3> <ul class="small-gap"> <li>Support <a class="reference external" href="http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors">LLVM vectors</a> @@ -34,9 +28,7 @@ vectors through <a class="reference internal" href="/native-client/reference/pna and performance is expected to become acceptable for version 37 of Chrome. More SIMD instructions will be added in later releases.</li> </ul> -</section></section><section id="chrome-pepper-35-31-mar-2014"> <h2 id="chrome-pepper-35-31-mar-2014">Chrome/Pepper 35 (31 Mar 2014)</h2> -<section id="id2"> <h3 id="id2">PNaCl</h3> <ul class="small-gap"> <li>Upgraded LLVM to version 3.4.</li> @@ -44,9 +36,7 @@ Chrome. More SIMD instructions will be added in later releases.</li> <li>Unstable pexes (i.e. non-finalized) with debug information can be loaded by Chrome, simplifying debugging with PNaCl. See <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html#debugging-pnacl-pexes"><em>Debugging PNaCl pexes</em></a></li> </ul> -</section></section><section id="chrome-pepper-34-20-feb-2014"> <h2 id="chrome-pepper-34-20-feb-2014">Chrome/Pepper 34 (20 Feb 2014)</h2> -<section id="id3"> <h3 id="id3">Pepper</h3> <ul class="small-gap"> <li>Filesystems can now be passed from JavaScript to NaCl. The resulting @@ -57,16 +47,13 @@ Chrome, simplifying debugging with PNaCl. See <a class="reference internal" href <a class="reference external" href="/native-client/pepper_dev/cpp/classpp_1_1_media_stream_video_track">pp::MediaStreamVideoTrack</a> for more details.</li> </ul> -</section><section id="id4"> <h3 id="id4">PNaCl</h3> <ul class="small-gap"> <li>Parallel translation: at least 1.7x faster, even with older pexes.</li> <li>Intelligent abbreviations in the bitcode: 20% reduction in binary size using the <a class="reference internal" href="/native-client/devguide/devcycle/building.html#pnacl-compress"><em>pnacl-compress</em></a> tool.</li> </ul> -</section></section><section id="chrome-pepper-33-16-dec-2013"> <h2 id="chrome-pepper-33-16-dec-2013">Chrome/Pepper 33 (16 Dec 2013)</h2> -<section id="portable-native-client"> <h3 id="portable-native-client">Portable Native Client</h3> <ul class="small-gap"> <li>PNaCl’s default C++ standard library is now LLVM’s own libc++, based on @@ -74,7 +61,6 @@ LLVM 3.3. This library now supports optional <code>setjmp</code>/<code>longjmp</ handling (see <a class="reference external" href="https://groups.google.com/forum/#!topic/native-client-discuss/0spfg6O04FM">announcement</a> for details).</li> </ul> -</section><section id="id5"> <h3 id="id5">SDK</h3> <ul class="small-gap"> <li>The <code>nacl_io</code> library now includes a FUSE mount.</li> @@ -82,7 +68,6 @@ for details).</li> nexes/pexes that are built (by default).</li> <li>“<code>make debug</code>” and “<code>make run</code>” have been fixed on Mac.</li> </ul> -</section></section><section id="pnacl-enabled-by-default-in-chrome-31-12-nov-2013"> <h2 id="pnacl-enabled-by-default-in-chrome-31-12-nov-2013">PNaCl enabled by default in Chrome 31 (12 Nov 2013)</h2> <ul class="small-gap"> <li>Portable Native Client (PNaCl) is enabled by default in Chrome 31. See @@ -101,7 +86,6 @@ The PNaCl ABI will remain stable starting with the release of Chrome 31.</li> </ul> </li> </ul> -</section><section id="pnacl-in-chrome-30-dev-channel-01-aug-2013"> <h2 id="pnacl-in-chrome-30-dev-channel-01-aug-2013">PNaCl in Chrome 30 Dev channel (01 Aug 2013)</h2> <ul class="small-gap"> <li>Portable Native Client (PNaCl) is currently available for preview in Chrome @@ -116,7 +100,6 @@ application, be sure to build your code with the latest version of the Native Client SDK.</li> <li>Update: PNaCl is not enabled by default in beta or stable versions of M30.</li> </ul> -</section><section id="pnacl-15-may-2013"> <h2 id="pnacl-15-may-2013">PNaCl (15 May 2013)</h2> <ul class="small-gap"> <li>Portable Native Client (PNaCl) is currently available for developer preview @@ -139,11 +122,9 @@ are not supported yet).</li> of PNaCl. If so, you will need to recompile your application with the pnacl toolchain in a new SDK bundle.</li> </ul> -</section><section id="pepper-27-12-april-2013"> <h2 id="pepper-27-12-april-2013">Pepper 27 (12 April 2013)</h2> <p>The Pepper 27 bundle features a significant number of new libraries that have been incorporated directly into the SDK.</p> -<section id="libraries"> <h3 id="libraries">Libraries</h3> <ul class="small-gap"> <li><p class="first">A number of libraries from the naclports project have been incorporated @@ -168,7 +149,6 @@ object. The <code>dlopen</code> example has been modified to demonstrate this functionality: reverse.cc is built into a shared object (.so) file, which is downloaded and opened using an <code>httpfs</code> mount.</li> </ul> -</section><section id="examples"> <h3 id="examples">Examples</h3> <ul class="small-gap"> <li>Each example now has a single <code>index.html</code> file, instead of multiple HTML @@ -184,7 +164,6 @@ Release configuration by specifying the following URL in Chrome: information about how different NaCl modules are loaded into <code>index.html</code>, see the <code>common.js</code> file in each example.</li> </ul> -</section><section id="build-tools-and-toolchains"> <h3 id="build-tools-and-toolchains">Build tools and toolchains</h3> <ul class="small-gap"> <li>Common makefiles, including <code>tools/common.mk</code>, can now handle source files @@ -192,12 +171,10 @@ located outside of an application’s root directory. For example, a Makefil for an application can specify a source file to compile such as <code>../../some/other/place.cpp</code>.</li> </ul> -</section></section><section id="pepper-26-29-march-2013"> <h2 id="pepper-26-29-march-2013">Pepper 26 (29 March 2013)</h2> <p>The Pepper 26 bundle includes a new HTTP filesystem type in the nacl_mounts library (which has been renamed nacl_io), changes to the example Makefiles, a simple new 3D example, and a threaded file IO example.</p> -<section id="id6"> <h3 id="id6">Build tools and toolchains</h3> <ul class="small-gap"> <li><p class="first">Makefiles have been changed significantly:</p> @@ -218,7 +195,6 @@ with all toolchains.</li> the same set of header files as host builds. Previously host and NaCl builds used different headers, which could cause build problems.</li> </ul> -</section><section id="id7"> <h3 id="id7">Libraries</h3> <ul class="small-gap"> <li>The nacl_mounts library has been renamed <strong>nacl_io</strong>, and has been expanded @@ -226,7 +202,6 @@ with a new type of mount, httpfs, which can be used to read URLs via HTTP. For details see <code>include/nacl_io/nacl_io.h</code>, as well as the <code>hello_nacl_io</code> example.</li> </ul> -</section><section id="id8"> <h3 id="id8">Examples</h3> <ul class="small-gap"> <li>A new example, <strong>hello_world_instance3d</strong>, has been added to demonstrate a @@ -235,14 +210,12 @@ simplified 3D app.</li> thread. The example demonstrates how to use the MessageLoop API and blocking callbacks on a thread.</li> </ul> -</section><section id="general"> <h3 id="general">General</h3> <ul class="small-gap"> <li>Old bundles (<code>pepper_20</code> and earlier) have been removed from the Native Client SDK Manifest, and will no longer be updated by the <code>naclsdk</code> command.</li> </ul> -</section></section><section id="pepper-25-21-december-2012"> <h2 id="pepper-25-21-december-2012">Pepper 25 (21 December 2012)</h2> <p>The Pepper 25 bundle features an ARM toolchain to build Native Client modules for ARM devices, two new Pepper APIs (including the MessageLoop API, which lets @@ -251,7 +224,6 @@ which provides a virtual file system that you can use with standard C file operations, and ppapi_main, which lets you implement a Native Client module using a simple ppapi_main function), and two new examples that demonstrate how to use the nacl_mounts and ppapi_main libraries.</p> -<section id="id9"> <h3 id="id9">Build tools and toolchains</h3> <ul class="small-gap"> <li><p class="first">The SDK includes a new toolchain to build Native Client executables (.nexe @@ -275,7 +247,6 @@ Native Client manifest (.nmf file) that references those three .nexe files.</li> the <code>examples/</code> directory to the <code>tools/</code> directory. On Windows, you can run <code>httpd.cmd</code> (in the <code>examples/</code> directory) to start the server.</li> </ul> -</section><section id="ppapi"> <h3 id="ppapi">PPAPI</h3> <p>Pepper 25 includes two new APIs:</p> <ul class="small-gap"> @@ -290,7 +261,6 @@ For a C++ example of how to use the MessageLoop API, see cannot make asynchronous PPAPI calls on a background thread without creating and using a message loop.</li> </ul> -</section><section id="id10"> <h3 id="id10">Libraries</h3> <p>The SDK includes two new libraries:</p> <ul class="small-gap"> @@ -325,7 +295,6 @@ how to use ppapi_main, see examples/hello_world_stdio.</li> <p>Header files for the new libraries are in the <code>include/</code> directory, source files are in the <code>src/</code> directory, and compiled libraries are in the <code>lib/</code> directory.</p> -</section><section id="id11"> <h3 id="id11">Examples</h3> <ul class="small-gap"> <li><p class="first">The SDK includes two new examples:</p> @@ -362,13 +331,11 @@ Chrome is closed, the local server is shut down as well.</li> source dependencies, and invokes the build rules in a separate file (common.mk).</li> </ul> -</section></section><section id="pepper-24-5-december-2012"> <h2 id="pepper-24-5-december-2012">Pepper 24 (5 December 2012)</h2> <p>The Pepper 24 bundle features a new, experimental toolchain called PNaCl (short for “Portable Native Client”), a new library (pthreads-win32) for the Windows SDK, and an expanded list of attributes for Pepper 3D contexts that lets applications specify a GPU preference for low power or performance.</p> -<section id="id12"> <h3 id="id12">Build tools and toolchains</h3> <ul class="small-gap"> <li>The SDK includes a new, experimental toolchain called <a class="reference external" href="http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf">PNaCl</a> (pronounced @@ -385,7 +352,6 @@ determine the architecture of .nexe files. That means you can change the names of your .nexe files and <code>create_nmf.py</code> will still be able to generate the appropriate Native Client manifest file for your application.</li> </ul> -</section><section id="id14"> <h3 id="id14">Examples</h3> <ul class="small-gap"> <li>The SDK examples now build with four toolchains: the glibc and newlib @@ -397,7 +363,6 @@ builds both a debug and a release version.</li> drawing function is now set up as the Flush() callback, which allows 2D drawing to occur as quickly as possible.</li> </ul> -</section><section id="id15"> <h3 id="id15">PPAPI</h3> <ul class="small-gap"> <li>When creating a 3D rendering context, the <a class="reference external" href="/native-client/pepper_stable/c/group___enums#ga7df48e1c55f6401beea2a1b9c07967e8">attribute list</a> @@ -405,7 +370,6 @@ for the context can specify whether to prefer low power or performance for the GPU. Contexts with a low power preference may be created on an integrated GPU; contexts with a performance preference may be created on a discrete GPU.</li> </ul> -</section><section id="windows-sdk"> <h3 id="windows-sdk">Windows SDK</h3> <ul class="small-gap"> <li>The Windows SDK includes the pthreads-win32 library to assist in porting from @@ -414,13 +378,11 @@ plug-in (.dll). See pepper_24/include/win/pthread.h and pepper_24/src/pthread/README for additional information.</li> <li>The update utility naclsdk.bat works when it is run from a path with spaces.</li> </ul> -</section></section><section id="pepper-23-15-october-2012"> <h2 id="pepper-23-15-october-2012">Pepper 23 (15 October 2012)</h2> <p>The Pepper 23 bundle includes support for the nacl-gdb debugger on Mac and 32-bit Windows, resources to enable hosted development on Linux, and changes to make the SDK examples compliant with version 2 of the Chrome Web Store manifest file format.</p> -<section id="tools"> <h3 id="tools">Tools</h3> <ul class="small-gap"> <li>The <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html#using-gdb"><em>nacl-gdb debugger</em></a> now works on all systems (Mac, @@ -432,7 +394,6 @@ system, and a “<code>*</code>” if the bundle has an update available information about a bundle, use the command <code>naclsdk info <bundle></code> (for example, <code>naclsdk info pepper_28</code>).</li> </ul> -</section><section id="linux-sdk"> <h3 id="linux-sdk">Linux SDK</h3> <ul class="small-gap"> <li><p class="first">Developers using the Linux SDK now have resources, including pre-built @@ -474,7 +435,6 @@ Note that you must set the <code>CHROME_PATH</code> environment variable and sta </ul> </li> </ul> -</section><section id="id16"> <h3 id="id16">Examples</h3> <ul class="small-gap"> <li>On Linux and Windows systems, most of the examples now build with three @@ -491,7 +451,6 @@ onclick="..."></code>). See <a class="reference external" href="/e a list of changes between version 1 and version 2 of the manifest file format, and a support schedule for applications that use version 1.</li> </ul> -</section><section id="id17"> <h3 id="id17">PPAPI</h3> <ul class="small-gap"> <li><a class="reference external" href="/native-client/pepper_stable/c/group___enums#ga21b811ac0484a214a8751aa3e1c959d9">PP_InputEvent_Modifier</a> @@ -499,12 +458,10 @@ has two new enum values (_ISLEFT and _ISRIGHT).</li> <li>The memory leak in the <a class="reference external" href="/native-client/pepper_stable/c/struct_p_p_b___web_socket__1__0">WebSocket</a> API has been fixed.</li> </ul> -</section></section><section id="pepper-22-22-august-2012"> <h2 id="pepper-22-22-august-2012">Pepper 22 (22 August 2012)</h2> <p>The Pepper 22 bundle includes a <strong>command-line debugger</strong>, resources to enable <strong>hosted development on Windows</strong>, and changes to the example Makefiles (each example now builds both a debug and a release version).</p> -<section id="id18"> <h3 id="id18">Tools</h3> <ul class="small-gap"> <li>The SDK now includes a <strong>command-line debugger</strong> that you can use to debug @@ -512,7 +469,6 @@ Native Client modules. See <a class="reference internal" href="/native-client/de nacl-gdb only works on 64-bit Windows, 64-bit Linux, and 32-bit Linux systems. Support for Mac and 32-bit Windows systems will be added soon.</li> </ul> -</section><section id="id19"> <h3 id="id19">Windows SDK</h3> <ul class="small-gap"> <li><p class="first">Developers using the Windows SDK can now <strong>build a module as a Pepper @@ -561,7 +517,6 @@ or <a class="reference external" href="http://www.chromium.org/nativeclient/how- In the future, the SDK will include resources for hosted development on Mac and Linux as well as Windows. </aside> -</section><section id="id20"> <h3 id="id20">Examples</h3> <ul class="small-gap"> <li>Each example in the SDK now builds both a debug and a release version. As @@ -576,13 +531,12 @@ in each example’s web page, attaches event listeners to monitor the loadin of the module, and implements handleMessage() to respond to messages sent from the NaCl module to the JavaScript side of the application</li> </ul> -</section><section id="id21"> <h3 id="id21">PPAPI</h3> <ul class="small-gap"> <li>The <code>CompletionCallbackFactory</code> class template now takes a thread traits class as its second parameter. For details see the <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_completion_callback_factory#details">CompletionCallbackFactory class template reference</a>.</li> </ul> -</section></section></section> +</section> {{/partials.standard_nacl_article}} diff --git a/native_client_sdk/doc_generated/sitemap.html b/native_client_sdk/doc_generated/sitemap.html index 764dd2ca1f..88b6b3f441 100644 --- a/native_client_sdk/doc_generated/sitemap.html +++ b/native_client_sdk/doc_generated/sitemap.html @@ -378,6 +378,10 @@ <li class="toctree-l2"><a class="reference internal" href="/native-client/reference/sandbox_internals/x86-64-sandbox.html#list-of-pseudo-instructions">List of Pseudo-instructions</a></li> </ul> </li> +<li class="toctree-l1"><a class="reference internal" href="/native-client/reference/design-docs.html">Design Documents</a><ul class="small-gap"> +<li class="toctree-l2"><a class="reference internal" href="/native-client/reference/design-docs.html#obsolete-not-implemented">Obsolete (not implemented)</a></li> +</ul> +</li> <li class="toctree-l1"><a class="reference internal" href="/native-client/publications-and-presentations.html">Publications and Presentations</a><ul class="small-gap"> <li class="toctree-l2"><a class="reference internal" href="/native-client/publications-and-presentations.html#recent-talks-and-demos">Recent talks and demos</a></li> <li class="toctree-l2"><a class="reference internal" href="/native-client/publications-and-presentations.html#publications">Publications</a></li> diff --git a/native_client_sdk/src/build_tools/build_sdk.py b/native_client_sdk/src/build_tools/build_sdk.py index e451b46f52..d4e7f0c700 100755 --- a/native_client_sdk/src/build_tools/build_sdk.py +++ b/native_client_sdk/src/build_tools/build_sdk.py @@ -63,7 +63,7 @@ GYPBUILD_DIR = 'gypbuild' options = None - # Map of: ToolchainName: (PackageName, SDKDir). +# Map of: ToolchainName: (PackageName, SDKDir). TOOLCHAIN_PACKAGE_MAP = { 'newlib': ('nacl_x86_newlib', '%(platform)s_x86_newlib'), 'bionic': ('nacl_arm_bionic', '%(platform)s_arm_bionic'), @@ -406,7 +406,7 @@ def GypNinjaInstall(pepperdir, toolchains): InstallFiles(ninja_out_dir, os.path.join(pepperdir, 'tools'), tools_files) # Add ARM binaries - if platform == 'linux': + if platform == 'linux' and not options.no_arm_trusted: tools_files = [ ['irt_core_newlib_arm.nexe', 'irt_core_arm.nexe'], ['irt_core_newlib_arm.nexe', 'irt_core_arm.nexe'], @@ -525,6 +525,8 @@ def GypNinjaBuild(arch, gyp_py_script, gyp_file, targets, 'arm_float_abi=hard'] if force_arm_gcc: gyp_defines.append('nacl_enable_arm_gcc=1') + if options.no_arm_trusted: + gyp_defines.append('disable_cross_trusted=1') if getos.GetPlatform() == 'mac': gyp_defines.append('clang=1') @@ -888,6 +890,8 @@ def main(args): action='store_true') parser.add_option('--mac-sdk', help='Set the mac-sdk (e.g. 10.6) to use when building with ninja.') + parser.add_option('--no-arm-trusted', action='store_true', + help='Disable building of ARM trusted components (sel_ldr, etc).') # To setup bash completion for this command first install optcomplete # and then add this line to your .bashrc: @@ -981,6 +985,7 @@ def main(args): oshelpers.Copy(['-r', srcdir, bionicdir]) else: BuildStepUntarToolchains(pepperdir, toolchains) + BuildStepBuildToolchains(pepperdir, toolchains) BuildStepUpdateHelpers(pepperdir, True) diff --git a/native_client_sdk/src/build_tools/buildbot_run.py b/native_client_sdk/src/build_tools/buildbot_run.py index c24c6df556..374155d3f4 100755 --- a/native_client_sdk/src/build_tools/buildbot_run.py +++ b/native_client_sdk/src/build_tools/buildbot_run.py @@ -87,6 +87,11 @@ def StepTestSDK(): ]) cmd.extend([sys.executable, 'test_sdk.py']) + + # TODO(noelallen): crbug 386332 + # For Bionic SDK, only build do a build test until we have hardware. + if 'bionic' in os.getenv('BUILDBOT_BUILDERNAME', ''): + cmd.extend(['build_examples', 'copy_tests', 'build_tests']) Run(cmd, cwd=SCRIPT_DIR) @@ -112,9 +117,6 @@ def main(args): # to pass --build-only argument. if os.getenv('BUILDBOT_BUILDERNAME', '').endswith('build'): options.build_only = True - # TODO(noelallen): Enable testing on bionic when we have an ARM solution. - if 'bionic' in os.getenv('BUILDBOT_BUILDERNAME', ''): - options.build_only = True StepArmRunHooks() StepRunUnittests() diff --git a/native_client_sdk/src/build_tools/json/naclsdk_manifest2.json b/native_client_sdk/src/build_tools/json/naclsdk_manifest2.json index 5d6a0bbce7..07c16f2eca 100644 --- a/native_client_sdk/src/build_tools/json/naclsdk_manifest2.json +++ b/native_client_sdk/src/build_tools/json/naclsdk_manifest2.json @@ -37,178 +37,6 @@ "archives": [ { "checksum": { - "sha1": "32c221b3f6bb58e160e3c1bd8a1e2330e3f411b4" - }, - "host_os": "all", - "size": 33470786, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/27.0.1453.110/naclports.tar.bz2" - }, - { - "checksum": { - "sha1": "f82e34527132e0891ac18531be04d98aa7e5c853" - }, - "host_os": "linux", - "size": 248844076, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/27.0.1453.110/naclsdk_linux.tar.bz2" - }, - { - "checksum": { - "sha1": "cc9a50b5afcf0fdcc6c336dca74e077601441194" - }, - "host_os": "mac", - "size": 219590087, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/27.0.1453.110/naclsdk_mac.tar.bz2" - }, - { - "checksum": { - "sha1": "a4135c5449fac83fb745896f5e807ea09a36a4fb" - }, - "host_os": "win", - "size": 234868912, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/27.0.1453.110/naclsdk_win.tar.bz2" - } - ], - "description": "Chrome 27 bundle, revision 202711", - "name": "pepper_27", - "recommended": "no", - "repath": "pepper_27", - "revision": 202711, - "stability": "post_stable", - "version": 27 - }, - { - "archives": [ - { - "checksum": { - "sha1": "b583caff514386237531cf843a08dfbffdce7ff0" - }, - "host_os": "all", - "size": 33433731, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/28.0.1500.95/naclports.tar.bz2" - }, - { - "checksum": { - "sha1": "7bfcf86ba2a77e71382bdac638b8f7deb9fd0a31" - }, - "host_os": "linux", - "size": 264136704, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/28.0.1500.95/naclsdk_linux.tar.bz2" - }, - { - "checksum": { - "sha1": "c22a704d9277081320e711ba43966db0e3da1ec2" - }, - "host_os": "mac", - "size": 231091004, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/28.0.1500.95/naclsdk_mac.tar.bz2" - }, - { - "checksum": { - "sha1": "910f0c61984210048b758f6c19d6008ddcdcdc3c" - }, - "host_os": "win", - "size": 248632304, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/28.0.1500.95/naclsdk_win.tar.bz2" - } - ], - "description": "Chrome 28 bundle, revision 213514", - "name": "pepper_28", - "recommended": "no", - "repath": "pepper_28", - "revision": 213514, - "stability": "post_stable", - "version": 28 - }, - { - "archives": [ - { - "checksum": { - "sha1": "b5573d7ad48f824f674da4b8c714ffee54ef13aa" - }, - "host_os": "all", - "size": 74342681, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/29.0.1547.76/naclports.tar.bz2" - }, - { - "checksum": { - "sha1": "0906db51a5daf9d697be5f0d137eb68120dfe32a" - }, - "host_os": "linux", - "size": 261176184, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/29.0.1547.76/naclsdk_linux.tar.bz2" - }, - { - "checksum": { - "sha1": "820e5da6846ecc8a206bb13411b8b36fb9c1cef2" - }, - "host_os": "mac", - "size": 228346093, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/29.0.1547.76/naclsdk_mac.tar.bz2" - }, - { - "checksum": { - "sha1": "3de50531664b387c3d8da947ab1dfc84b4f59e9b" - }, - "host_os": "win", - "size": 244722472, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/29.0.1547.76/naclsdk_win.tar.bz2" - } - ], - "description": "Chrome 29 bundle. Chrome revision: 223446. NaCl revision: 11601", - "name": "pepper_29", - "recommended": "no", - "repath": "pepper_29", - "revision": 223446, - "stability": "post_stable", - "version": 29 - }, - { - "archives": [ - { - "checksum": { - "sha1": "32ab7dedeab475d978f0dd4dbe6aadef7bb5650a" - }, - "host_os": "all", - "size": 76522649, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/30.0.1599.101/naclports.tar.bz2" - }, - { - "checksum": { - "sha1": "e377aec36ea13fc856799adeeeedc4abb18a99fd" - }, - "host_os": "linux", - "size": 268541497, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/30.0.1599.101/naclsdk_linux.tar.bz2" - }, - { - "checksum": { - "sha1": "2a2411580b4d53277240e910d3f1fe3d9cc9731f" - }, - "host_os": "mac", - "size": 237920853, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/30.0.1599.101/naclsdk_mac.tar.bz2" - }, - { - "checksum": { - "sha1": "389266df9873f0dcb0bc35e4c52ec340d1e20912" - }, - "host_os": "win", - "size": 254298083, - "url": "https://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/30.0.1599.101/naclsdk_win.tar.bz2" - } - ], - "description": "Chrome 30 bundle. Chrome revision: 227552. NaCl revision: 11988", - "name": "pepper_30", - "recommended": "no", - "repath": "pepper_30", - "revision": 227552, - "stability": "post_stable", - "version": 30 - }, - { - "archives": [ - { - "checksum": { "sha1": "c669f3d3a31bcb389d36889151a3af6354b5343f" }, "host_os": "all", @@ -366,6 +194,16 @@ }, { "archives": [], + "description": "Chrome 37 bundle, revision xxxxx", + "name": "pepper_37", + "recommended": "no", + "repath": "pepper_37", + "revision": 0, + "stability": "post_stable", + "version": 37 + }, + { + "archives": [], "description": "Chrome Canary", "name": "pepper_canary", "recommended": "no", diff --git a/native_client_sdk/src/doc/_sphinxext/chromesite_builder.py b/native_client_sdk/src/doc/_sphinxext/chromesite_builder.py index c44b3f7577..6c133bff41 100644 --- a/native_client_sdk/src/doc/_sphinxext/chromesite_builder.py +++ b/native_client_sdk/src/doc/_sphinxext/chromesite_builder.py @@ -103,11 +103,13 @@ class ChromesiteHTMLTranslator(HTMLTranslator): def visit_section(self, node): # chromesite needs <section> instead of <div class='section'> self.section_level += 1 - self.body.append(self.starttag(node, 'section')) + if self.section_level == 1: + self.body.append(self.starttag(node, 'section')) def depart_section(self, node): + if self.section_level == 1: + self.body.append('</section>') self.section_level -= 1 - self.body.append('</section>') def visit_image(self, node): # Paths to images in .rst sources should be absolute. This visitor does the diff --git a/native_client_sdk/src/doc/devguide/devcycle/debugging.rst b/native_client_sdk/src/doc/devguide/devcycle/debugging.rst index 974b1e7dee..14cba30766 100644 --- a/native_client_sdk/src/doc/devguide/devcycle/debugging.rst +++ b/native_client_sdk/src/doc/devguide/devcycle/debugging.rst @@ -245,13 +245,15 @@ that copy in your application's manifest file: { "program": { - "pnacl-translate": { - "url": "release_version.pexe", - "optlevel": 2 - }, - "pnacl-debug": { - "url": "debug_version.bc", - "optlevel": 0 + "portable": { + "pnacl-translate": { + "url": "release_version.pexe", + "optlevel": 2 + }, + "pnacl-debug": { + "url": "debug_version.bc", + "optlevel": 0 + } } } } diff --git a/native_client_sdk/src/doc/reference/design-docs.rst b/native_client_sdk/src/doc/reference/design-docs.rst new file mode 100644 index 0000000000..b1f19b5fd5 --- /dev/null +++ b/native_client_sdk/src/doc/reference/design-docs.rst @@ -0,0 +1,55 @@ +================ +Design Documents +================ + +This is a list of design documents for Native Client. This list +generally covers designs that were implemented. It does not cover +PPAPI (Pepper). + +Dynamic loading and linking: + +* `Dynamic loading: Options for supporting dynamic loading, and how they interact with dynamic libraries <http://code.google.com/p/nativeclient/wiki/DynamicLoadingOptions>`_ (2010) + +Handling faults (hardware exceptions) in untrusted code: + +* `NaCl untrusted fault handling: guide to the implementation <https://docs.google.com/a/chromium.org/document/d/1T2KQitbOBz_ALQtr4ONcZcSNCIKNla3DI7t6dMcx5AE/edit>`_ + +Sandbox security on Windows: + +* `Native Client's NTDLL patch on x86-64 Windows <https://src.chromium.org/viewvc/native_client/trunk/src/native_client/documentation/windows_ntdll_patch.txt?revision=HEAD>`_ (2012) + +Debugging using GDB: + +* `Providing a GDB debug stub integrated into native_client <https://docs.google.com/a/chromium.org/document/d/1OtVmgJFC7X7aa57DnyiL4V10vAVax_vcRJp4Mw86lIU/edit>`_ (2012). This was the main design doc for NaCl's GDB debug stub. +* `Native Client Support for Debugging, Crash Reporting and Hardware Exception Handling -- high level design <https://docs.google.com/a/google.com/document/d/1tu2FEA4EKhBH669iUgRZBDBcEd6jzNQ-0OVn9JI4_qk/edit>`_ (Jan 2012) +* `NaCl: three kinds of crash handling <https://docs.google.com/a/chromium.org/document/d/19qkl5R4lg-AIDf648Ml-gLRq6eZscjvvdMNWkVu2wLk/edit>`_ (2012). This is an earlier document. It contains notes on trusted vs. untrusted crash handling, vs. GDB support. + +PNaCl: + +* `Stability of the PNaCl bitcode ABI <https://docs.google.com/a/google.com/document/d/1xUlWyXnaRnIUBnmKdOBkgq2O9OqfvaRBLaz82pNdKt0/edit>`_ (2013). This is an overview of ABI stability issues and the features of LLVM IR that PNaCl is removing. +* `Incrementally simplifying the PNaCl bitcode format <https://docs.google.com/a/chromium.org/document/d/1HvZJVwS9KeTc0jUvoQjbLapRbStHk3mZ0rPDUHNN96Y/edit>`_ (2013) +* `SJLJ EH: C++ exception handling in PNaCl using setjmp()+longjmp() <https://docs.google.com/a/chromium.org/document/d/1Bub1bV_IIDZDhdld-zTULE2Sv0KNbOXk33KOW8o0aR4/edit>`_ (2013) + +Security hardening: + +* `Hiding PNaCl's x86-64 sandbox base address <https://docs.google.com/a/chromium.org/document/d/1eskaI4353XdsJQFJLRnZzb_YIESQx4gNRzf31dqXVG8/edit>`_ (2013). This was part of the security hardening we did for enabling PNaCl on the open web. + +MIPS support: + +* `Design for the NaCl MIPS sandbox <https://code.google.com/p/nativeclient/issues/attachmentText?id=2275&aid=22750018000&name=native-client-mips-0.4.txt>`_ (2012) + +Cleanup work: + +* `Removing NaCl's dependency on Chromium <https://docs.google.com/a/chromium.org/document/d/1lycqf4yPMC84011yvuyO_50V8c8COQ8dAe5rNvbeB9o/edit>`_ (2012) + +DEPS rolls: + +* `Semi-automated NaCl DEPS rolls: Updates to nacl_revision field in Chromium's DEPS file <https://docs.google.com/a/chromium.org/document/d/1jHoLo9I3CCS1_-4KlIq1OiEMv9cmMuXES2Z9JVpmPtY/edit>`_ (2013). This is a description of current practice rather than a design doc. + +Obsolete (not implemented) +========================== + +PNaCl multi-threading support: The following proposals do not reflect what was implemented in PNaCl in the end. They are listed here for historical reference. + +* `Multi-threading support for a first release of PNaCl <https://docs.google.com/a/chromium.org/document/d/1HcRiGOaaPLk7pQrGnjXceoM7Px3IwOjjwdiVvJVQNr4/edit>`_ (2013): Proposal for mutex_v2/cond_v2 IRT interfaces. +* `Explicit vs. implicit atomicity guarantees in PNaCl <https://docs.google.com/a/chromium.org/document/d/1HcRiGOaaPLk7pQrGnjXceoM7Px3IwOjjwdiVvJVQNr4/edit>`_ (2013): Discussion about how to handle atomic memory operations. diff --git a/native_client_sdk/src/doc/reference/pnacl-c-cpp-language-support.rst b/native_client_sdk/src/doc/reference/pnacl-c-cpp-language-support.rst index af1ff310aa..6fb875149d 100644 --- a/native_client_sdk/src/doc/reference/pnacl-c-cpp-language-support.rst +++ b/native_client_sdk/src/doc/reference/pnacl-c-cpp-language-support.rst @@ -215,9 +215,10 @@ of SIMD vector datatypes and operations which map well to modern architectures and offer performance which matches or approaches hardware-specific uses. -SIMD vector support was added to Portable Native Client for version 37 -of Chrome and more features, including performance enhancements, are -expected to be added in subsequent releases. +SIMD vector support was added to Portable Native Client for version 37 of Chrome +and more features, including performance enhancements, have been added in +subsequent releases, see the :ref:`Release Notes <sdk-release-notes>` for more +details. Hand-Coding Vector Extensions ----------------------------- @@ -254,24 +255,36 @@ elements of all ``0`` or all ``1``: return ret; } -Vector datatypes are currently expected to be 128-bit wide with one of -the following element types: - -============ ============ ================ -Type Num Elements Vector Bit Width -============ ============ ================ -``uint8_t`` 16 128 -``int8_t`` 16 128 -``uint16_t`` 8 128 -``int16_t`` 8 128 -``uint32_t`` 4 128 -``int32_t`` 4 128 -``float`` 4 128 -============ ============ ================ +Vector datatypes are currently expected to be 128-bit wide with one of the +following element types, and they're expected to be aligned to the underlying +element's bit width (loads and store will otherwise be broken up into scalar +accesses to prevent faults): + +============ ============ ================ ====================== +Type Num Elements Vector Bit Width Expected Bit Alignment +============ ============ ================ ====================== +``uint8_t`` 16 128 8 +``int8_t`` 16 128 8 +``uint16_t`` 8 128 16 +``int16_t`` 8 128 16 +``uint32_t`` 4 128 32 +``int32_t`` 4 128 32 +``float`` 4 128 32 +============ ============ ================ ====================== 64-bit integers and double-precision floating point will be supported in a future release, as will 256-bit and 512-bit vectors. +Vector element bit width alignment can be stated explicitly (this is assumed by +PNaCl, but not necessarily by other compilers), and smaller alignments can also +be specified: + +.. naclcode:: + + typedef int v4s_element __attribute__((vector_size(16), aligned(4))); + typedef int v4s_unaligned __attribute__((vector_size(16), aligned(1))); + + The following operators are supported on vectors: +----------------------------------------------+ diff --git a/native_client_sdk/src/doc/sitemap.rst b/native_client_sdk/src/doc/sitemap.rst index 4b5ef241ab..e00c3b3e76 100644 --- a/native_client_sdk/src/doc/sitemap.rst +++ b/native_client_sdk/src/doc/sitemap.rst @@ -57,6 +57,7 @@ Contents: reference/sandbox_internals/index.rst reference/sandbox_internals/arm-32-bit-sandbox.rst reference/sandbox_internals/x86-64-sandbox.rst + reference/design-docs.rst publications-and-presentations.rst faq.rst help.rst diff --git a/native_client_sdk/src/examples/api/core/example.dsc b/native_client_sdk/src/examples/api/core/example.dsc index 885ad10dfe..4b17c97f50 100644 --- a/native_client_sdk/src/examples/api/core/example.dsc +++ b/native_client_sdk/src/examples/api/core/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'core', diff --git a/native_client_sdk/src/examples/api/file_io/example.dsc b/native_client_sdk/src/examples/api/file_io/example.dsc index e1eb3deb32..df6ea6338f 100644 --- a/native_client_sdk/src/examples/api/file_io/example.dsc +++ b/native_client_sdk/src/examples/api/file_io/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'file_io', diff --git a/native_client_sdk/src/examples/api/gamepad/example.dsc b/native_client_sdk/src/examples/api/gamepad/example.dsc index 20878604fb..464670f12e 100644 --- a/native_client_sdk/src/examples/api/gamepad/example.dsc +++ b/native_client_sdk/src/examples/api/gamepad/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'gamepad', diff --git a/native_client_sdk/src/examples/api/graphics_3d/example.dsc b/native_client_sdk/src/examples/api/graphics_3d/example.dsc index 6d637e3ef4..82a956e2b9 100644 --- a/native_client_sdk/src/examples/api/graphics_3d/example.dsc +++ b/native_client_sdk/src/examples/api/graphics_3d/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'graphics_3d', diff --git a/native_client_sdk/src/examples/api/input_event/example.dsc b/native_client_sdk/src/examples/api/input_event/example.dsc index 725a83c3e4..6e45712a47 100644 --- a/native_client_sdk/src/examples/api/input_event/example.dsc +++ b/native_client_sdk/src/examples/api/input_event/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'linux', 'win'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'linux', 'win'], 'TARGETS': [ { 'NAME' : 'input_event', diff --git a/native_client_sdk/src/examples/api/media_stream_audio/example.dsc b/native_client_sdk/src/examples/api/media_stream_audio/example.dsc index 8adc6e2a59..1cdf9381e2 100644 --- a/native_client_sdk/src/examples/api/media_stream_audio/example.dsc +++ b/native_client_sdk/src/examples/api/media_stream_audio/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'media_stream_audio', diff --git a/native_client_sdk/src/examples/api/media_stream_video/example.dsc b/native_client_sdk/src/examples/api/media_stream_video/example.dsc index 1011b9cdf3..7e007350ac 100644 --- a/native_client_sdk/src/examples/api/media_stream_video/example.dsc +++ b/native_client_sdk/src/examples/api/media_stream_video/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'media_stream_video', diff --git a/native_client_sdk/src/examples/api/mouse_cursor/example.dsc b/native_client_sdk/src/examples/api/mouse_cursor/example.dsc index 4b89b8f05e..8a829304d6 100644 --- a/native_client_sdk/src/examples/api/mouse_cursor/example.dsc +++ b/native_client_sdk/src/examples/api/mouse_cursor/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'mouse_cursor', diff --git a/native_client_sdk/src/examples/api/mouse_lock/example.dsc b/native_client_sdk/src/examples/api/mouse_lock/example.dsc index 626e3a2d18..f1c5be1be4 100644 --- a/native_client_sdk/src/examples/api/mouse_lock/example.dsc +++ b/native_client_sdk/src/examples/api/mouse_lock/example.dsc @@ -1,6 +1,6 @@ { 'DISABLE_PACKAGE': True, - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'mouse_lock', diff --git a/native_client_sdk/src/examples/api/network_monitor/example.dsc b/native_client_sdk/src/examples/api/network_monitor/example.dsc index 271b3adde1..44ba94f83e 100644 --- a/native_client_sdk/src/examples/api/network_monitor/example.dsc +++ b/native_client_sdk/src/examples/api/network_monitor/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'network_monitor', diff --git a/native_client_sdk/src/examples/api/socket/example.dsc b/native_client_sdk/src/examples/api/socket/example.dsc index a573c829b7..3c7df8a67c 100644 --- a/native_client_sdk/src/examples/api/socket/example.dsc +++ b/native_client_sdk/src/examples/api/socket/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'socket', diff --git a/native_client_sdk/src/examples/api/url_loader/example.dsc b/native_client_sdk/src/examples/api/url_loader/example.dsc index baafd66282..1ee83b4e9d 100644 --- a/native_client_sdk/src/examples/api/url_loader/example.dsc +++ b/native_client_sdk/src/examples/api/url_loader/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'url_loader', diff --git a/native_client_sdk/src/examples/api/var_array_buffer/example.dsc b/native_client_sdk/src/examples/api/var_array_buffer/example.dsc index 4b1f2960c6..699a7787ca 100644 --- a/native_client_sdk/src/examples/api/var_array_buffer/example.dsc +++ b/native_client_sdk/src/examples/api/var_array_buffer/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'var_array_buffer', diff --git a/native_client_sdk/src/examples/api/var_dictionary/example.dsc b/native_client_sdk/src/examples/api/var_dictionary/example.dsc index 1842eba5fc..90f146ee13 100644 --- a/native_client_sdk/src/examples/api/var_dictionary/example.dsc +++ b/native_client_sdk/src/examples/api/var_dictionary/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'var_dictionary', diff --git a/native_client_sdk/src/examples/api/websocket/example.dsc b/native_client_sdk/src/examples/api/websocket/example.dsc index c3d02fcedd..e48a3f179b 100644 --- a/native_client_sdk/src/examples/api/websocket/example.dsc +++ b/native_client_sdk/src/examples/api/websocket/example.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'websocket', diff --git a/native_client_sdk/src/examples/demo/nacl_io_demo/nacl_io_demo.c b/native_client_sdk/src/examples/demo/nacl_io_demo/nacl_io_demo.c index 226d50f662..d103c1f7c4 100644 --- a/native_client_sdk/src/examples/demo/nacl_io_demo/nacl_io_demo.c +++ b/native_client_sdk/src/examples/demo/nacl_io_demo/nacl_io_demo.c @@ -41,6 +41,16 @@ #define va_copy(d, s) ((d) = (s)) #endif +/** + * The location of MAX is inconsitantly between LIBCs, so instead + * we define it here for consistency. + */ +static int larger_int_of(int a, int b) { + if (a > b) + return a; + return b; +} + typedef struct { const char* name; HandleFunc function; @@ -312,8 +322,8 @@ static void* EchoThread(void* user_data) { int fd1 = open("/dev/jspipe1", O_RDWR | O_NONBLOCK); int fd2 = open("/dev/jspipe2", O_RDWR | O_NONBLOCK); int fd3 = open("/dev/jspipe3", O_RDWR | O_NONBLOCK); - int nfds = MAX(fd1, fd2); - nfds = MAX(nfds, fd3); + int nfds = larger_int_of(fd1, fd2); + nfds = larger_int_of(nfds, fd3); while (1) { fd_set readfds; FD_ZERO(&readfds); diff --git a/native_client_sdk/src/examples/tutorial/testing/example.dsc b/native_client_sdk/src/examples/tutorial/testing/example.dsc index 8284c1526c..2370efd9ed 100644 --- a/native_client_sdk/src/examples/tutorial/testing/example.dsc +++ b/native_client_sdk/src/examples/tutorial/testing/example.dsc @@ -6,7 +6,7 @@ 'NAME' : 'testing', 'TYPE' : 'main', 'SOURCES' : ['testing.cc'], - 'LIBS' : ['ppapi_simple', 'nacl_io', 'ppapi_cpp', 'ppapi', 'gtest', 'pthread'], + 'LIBS' : ['ppapi_simple', 'ppapi', 'gtest', 'nacl_io', 'ppapi_cpp', 'pthread'], 'CXXFLAGS': ['-Wno-sign-compare'] } ], diff --git a/native_client_sdk/src/examples/tutorial/testing/example.js b/native_client_sdk/src/examples/tutorial/testing/example.js index 627c5ca4fa..b51b988563 100644 --- a/native_client_sdk/src/examples/tutorial/testing/example.js +++ b/native_client_sdk/src/examples/tutorial/testing/example.js @@ -45,9 +45,14 @@ function handleMessage(event) { var msg = event.data; var firstColon = msg.indexOf(':'); var cmd = msg.substr(0, firstColon); + + if (cmd == 'testend') { + event.srcElement.postMessage({'testend' : ''}); + return; + } + var cmdFunctionName = cmd + 'Command'; var cmdFunction = window[cmdFunctionName]; - if (typeof(cmdFunction) !== 'function') { console.log('Unknown command: ' + cmd); console.log(' message: ' + msg); diff --git a/native_client_sdk/src/examples/tutorial/testing/index.html b/native_client_sdk/src/examples/tutorial/testing/index.html index 4fd2383475..37fcdd878c 100644 --- a/native_client_sdk/src/examples/tutorial/testing/index.html +++ b/native_client_sdk/src/examples/tutorial/testing/index.html @@ -17,7 +17,7 @@ .failed { background-color: #f00; } </style> </head> -<body {{attrs}}> +<body data-attrs="PS_EXIT_MESSAGE=testend" {{attrs}}> <h1>{{title}}</h1> <div id="listener"></div> <h2>Status: <code id="statusField">NO-STATUS</code></h2> diff --git a/native_client_sdk/src/libraries/gtest/library.dsc b/native_client_sdk/src/libraries/gtest/library.dsc index dd4ee37b8c..ce91ad3dd7 100644 --- a/native_client_sdk/src/libraries/gtest/library.dsc +++ b/native_client_sdk/src/libraries/gtest/library.dsc @@ -19,7 +19,6 @@ 'gtest-printers.cc', 'gtest-test-part.cc', 'gtest-typed-test.cc', - 'nacl_gtest_dummy_sys.cc', ], 'INCLUDES': [ # See comment below about gtest-internal-inl.h diff --git a/native_client_sdk/src/libraries/gtest/nacl_gtest_dummy_sys.cc b/native_client_sdk/src/libraries/gtest/nacl_gtest_dummy_sys.cc deleted file mode 100644 index 015ad094b5..0000000000 --- a/native_client_sdk/src/libraries/gtest/nacl_gtest_dummy_sys.cc +++ /dev/null @@ -1,40 +0,0 @@ -// Copyright (c) 2012 The Chromium Authors. All rights reserved. -// Use of this source code is governed by a BSD-style license that can be -// found in the LICENSE file. - -#if defined(__native_client__) -#include <errno.h> -#include <string.h> -#include <sys/types.h> -#endif - -extern "C" { - -#if defined(__native_client__) - -char* getcwd(char* buf, size_t size) __attribute__ ((weak)); -int unlink(const char* pathname) __attribute__ ((weak)); -int mkdir(const char* pathname, mode_t mode) __attribute__ ((weak)); - -char* getcwd(char* buf, size_t size) { - if (size < 2) { - errno = ERANGE; - return NULL; - } - - return strncpy(buf, ".", size); -} - -int unlink(const char* pathname) { - errno = ENOSYS; - return -1; -} - -int mkdir(const char* pathname, mode_t mode) { - errno = ENOSYS; - return -1; -} - -#endif - -} // extern "C" diff --git a/native_client_sdk/src/libraries/jsoncpp/library.dsc b/native_client_sdk/src/libraries/jsoncpp/library.dsc index 26f506a96f..6029ce2f3f 100644 --- a/native_client_sdk/src/libraries/jsoncpp/library.dsc +++ b/native_client_sdk/src/libraries/jsoncpp/library.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['bionic', 'newlib', 'glibc', 'pnacl', 'linux', 'win'], + 'TOOLS': ['bionic', 'newlib', 'glibc', 'bionic', 'pnacl', 'linux', 'win'], 'SEARCH': [ '../../../../third_party/jsoncpp/overrides/include/json', '../../../../third_party/jsoncpp/overrides/src/lib_json', diff --git a/native_client_sdk/src/libraries/libjpeg/library.dsc b/native_client_sdk/src/libraries/libjpeg/library.dsc index d5dd5c367c..a6579e12bb 100644 --- a/native_client_sdk/src/libraries/libjpeg/library.dsc +++ b/native_client_sdk/src/libraries/libjpeg/library.dsc @@ -1,6 +1,6 @@ { 'DISABLE': True, - 'TOOLS': ['newlib', 'glibc', 'linux', 'win'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'linux', 'win'], 'SEARCH': [ '../../../../third_party/libjpeg', ], diff --git a/native_client_sdk/src/libraries/nacl_io/devfs/dev_fs.cc b/native_client_sdk/src/libraries/nacl_io/devfs/dev_fs.cc index efe805525c..6dd7642419 100644 --- a/native_client_sdk/src/libraries/nacl_io/devfs/dev_fs.cc +++ b/native_client_sdk/src/libraries/nacl_io/devfs/dev_fs.cc @@ -20,6 +20,7 @@ #include "nacl_io/kernel_wrap_real.h" #include "nacl_io/node.h" #include "nacl_io/osunistd.h" +#include "nacl_io/passthroughfs/real_node.h" #include "nacl_io/pepper_interface.h" #include "sdk_util/auto_lock.h" @@ -33,24 +34,6 @@ namespace nacl_io { namespace { -class RealNode : public Node { - public: - RealNode(Filesystem* filesystem, int fd); - - virtual Error Read(const HandleAttr& attr, - void* buf, - size_t count, - int* out_bytes); - virtual Error Write(const HandleAttr& attr, - const void* buf, - size_t count, - int* out_bytes); - virtual Error GetStat(struct stat* stat); - - protected: - int fd_; -}; - class NullNode : public CharNode { public: explicit NullNode(Filesystem* filesystem) : CharNode(filesystem) {} @@ -125,44 +108,6 @@ class FsNode : public Node { Filesystem* other_fs_; }; -RealNode::RealNode(Filesystem* filesystem, int fd) : Node(filesystem), fd_(fd) { - SetType(S_IFCHR); -} - -Error RealNode::Read(const HandleAttr& attr, - void* buf, - size_t count, - int* out_bytes) { - *out_bytes = 0; - - size_t readcnt; - int err = _real_read(fd_, buf, count, &readcnt); - if (err) - return err; - - *out_bytes = static_cast<int>(readcnt); - return 0; -} - -Error RealNode::Write(const HandleAttr& attr, - const void* buf, - size_t count, - int* out_bytes) { - *out_bytes = 0; - - size_t writecnt; - int err = _real_write(fd_, buf, count, &writecnt); - if (err) - return err; - - *out_bytes = static_cast<int>(writecnt); - return 0; -} - -Error RealNode::GetStat(struct stat* stat) { - return _real_fstat(fd_, stat); -} - Error NullNode::Read(const HandleAttr& attr, void* buf, size_t count, diff --git a/native_client_sdk/src/libraries/nacl_io/html5fs/html5_fs.cc b/native_client_sdk/src/libraries/nacl_io/html5fs/html5_fs.cc index 430e49f4ae..f7a622fd74 100644 --- a/native_client_sdk/src/libraries/nacl_io/html5fs/html5_fs.cc +++ b/native_client_sdk/src/libraries/nacl_io/html5fs/html5_fs.cc @@ -147,15 +147,17 @@ Error Html5Fs::Rename(const Path& path, const Path& newpath) { if (error) return error; - const char* oldpath_full = GetFullPath(path).Join().c_str(); + std::string oldpath_full = GetFullPath(path).Join(); ScopedResource fileref_resource( - ppapi(), file_ref_iface_->Create(filesystem_resource_, oldpath_full)); + ppapi(), + file_ref_iface_->Create(filesystem_resource_, oldpath_full.c_str())); if (!fileref_resource.pp_resource()) return ENOENT; - const char* newpath_full = GetFullPath(newpath).Join().c_str(); + std::string newpath_full = GetFullPath(newpath).Join(); ScopedResource new_fileref_resource( - ppapi(), file_ref_iface_->Create(filesystem_resource_, newpath_full)); + ppapi(), + file_ref_iface_->Create(filesystem_resource_, newpath_full.c_str())); if (!new_fileref_resource.pp_resource()) return ENOENT; diff --git a/native_client_sdk/src/libraries/nacl_io/kernel_wrap_glibc.cc b/native_client_sdk/src/libraries/nacl_io/kernel_wrap_glibc.cc index 5e43c6c417..ed2ab0c404 100644 --- a/native_client_sdk/src/libraries/nacl_io/kernel_wrap_glibc.cc +++ b/native_client_sdk/src/libraries/nacl_io/kernel_wrap_glibc.cc @@ -157,7 +157,17 @@ EXTERN_C_BEGIN OP(getsockopt); \ OP(setsockopt); \ OP(socketpair); \ - OP(shutdown); + OP(shutdown); \ + \ + OP(access); \ + OP(unlink); \ + OP(fchdir); \ + OP(fchmod); \ + OP(fsync); \ + OP(fdatasync); \ + OP(lstat); \ + OP(readlink); \ + OP(utimes); // TODO(bradnelson): Add these as well. // OP(epoll_create); @@ -166,18 +176,15 @@ EXTERN_C_BEGIN // OP(epoll_pwait); // OP(ppoll); // OP(pselect); -// EXPAND_SYMBOL_LIST_OPERATION(DECLARE_REAL_PTR); int WRAP(chdir)(const char* pathname) { - RTN_ERRNO_IF(ki_chdir(pathname) < 0); - return 0; + ERRNO_RTN(ki_chdir(pathname)); } int WRAP(close)(int fd) { - RTN_ERRNO_IF(ki_close(fd) < 0); - return 0; + ERRNO_RTN(ki_close(fd)); } int WRAP(dup)(int fd, int* newfd) NOTHROW { @@ -187,8 +194,7 @@ int WRAP(dup)(int fd, int* newfd) NOTHROW { } int WRAP(dup2)(int fd, int newfd) NOTHROW { - RTN_ERRNO_IF(ki_dup2(fd, newfd) < 0); - return 0; + ERRNO_RTN(ki_dup2(fd, newfd)); } void WRAP(exit)(int status) { @@ -320,6 +326,53 @@ int WRAP(stat)(const char* pathname, struct nacl_abi_stat* nacl_buf) { return 0; } +int WRAP(lstat)(const char* pathname, struct nacl_abi_stat* nacl_buf) { + struct stat buf; + memset(&buf, 0, sizeof(struct stat)); + int res = ki_lstat(pathname, &buf); + RTN_ERRNO_IF(res < 0); + stat_to_nacl_stat(&buf, nacl_buf); + return 0; +} + +int WRAP(readlink)(const char* pathname, + char* buf, + size_t count, + size_t* nread) { + int rtn = ki_readlink(pathname, buf, count); + RTN_ERRNO_IF(rtn < 0); + *nread = rtn; + return 0; +} + +int WRAP(utimes)(const char *filename, const struct timeval *times) { + ERRNO_RTN(ki_utimes(filename, times)); +} + +int WRAP(access)(const char* pathname, int amode) { + ERRNO_RTN(ki_access(pathname, amode)); +} + +int WRAP(unlink)(const char* pathname) { + ERRNO_RTN(ki_unlink(pathname)); +} + +int WRAP(fchdir)(int fd) { + ERRNO_RTN(ki_fchdir(fd)); +} + +int WRAP(fchmod)(int fd, mode_t mode) { + ERRNO_RTN(ki_fchmod(fd, mode)); +} + +int WRAP(fsync)(int fd) { + ERRNO_RTN(ki_fsync(fd)); +} + +int WRAP(fdatasync)(int fd) { + ERRNO_RTN(ki_fdatasync(fd)); +} + int WRAP(write)(int fd, const void* buf, size_t count, size_t* nwrote) { ssize_t signed_nwrote = ki_write(fd, buf, count); *nwrote = static_cast<size_t>(signed_nwrote); @@ -337,23 +390,19 @@ int WRAP(accept)(int sockfd, } int WRAP(bind)(int sockfd, const struct sockaddr* addr, socklen_t addrlen) { - RTN_ERRNO_IF(ki_bind(sockfd, addr, addrlen) < 0); - return 0; + ERRNO_RTN(ki_bind(sockfd, addr, addrlen)); } int WRAP(connect)(int sockfd, const struct sockaddr* addr, socklen_t addrlen) { - RTN_ERRNO_IF(ki_connect(sockfd, addr, addrlen) < 0); - return 0; + ERRNO_RTN(ki_connect(sockfd, addr, addrlen)); } int WRAP(getpeername)(int sockfd, struct sockaddr* addr, socklen_t* addrlen) { - RTN_ERRNO_IF(ki_getpeername(sockfd, addr, addrlen) < 0); - return 0; + ERRNO_RTN(ki_getpeername(sockfd, addr, addrlen)); } int WRAP(getsockname)(int sockfd, struct sockaddr* addr, socklen_t* addrlen) { - RTN_ERRNO_IF(ki_getsockname(sockfd, addr, addrlen) < 0); - return 0; + ERRNO_RTN(ki_getsockname(sockfd, addr, addrlen)); } int WRAP(getsockopt)(int sockfd, @@ -361,8 +410,7 @@ int WRAP(getsockopt)(int sockfd, int optname, void* optval, socklen_t* optlen) { - RTN_ERRNO_IF(ki_getsockopt(sockfd, level, optname, optval, optlen) < 0); - return 0; + ERRNO_RTN(ki_getsockopt(sockfd, level, optname, optval, optlen)); } int WRAP(setsockopt)(int sockfd, @@ -370,13 +418,11 @@ int WRAP(setsockopt)(int sockfd, int optname, const void* optval, socklen_t optlen) { - RTN_ERRNO_IF(ki_setsockopt(sockfd, level, optname, optval, optlen) < 0); - return 0; + ERRNO_RTN(ki_setsockopt(sockfd, level, optname, optval, optlen)); } int WRAP(listen)(int sockfd, int backlog) { - RTN_ERRNO_IF(ki_listen(sockfd, backlog) < 0); - return 0; + ERRNO_RTN(ki_listen(sockfd, backlog)); } int WRAP(recv)(int sockfd, void* buf, size_t len, int flags, int* count) { diff --git a/native_client_sdk/src/libraries/nacl_io/kernel_wrap_newlib.cc b/native_client_sdk/src/libraries/nacl_io/kernel_wrap_newlib.cc index af3ecca958..e992c2784b 100644 --- a/native_client_sdk/src/libraries/nacl_io/kernel_wrap_newlib.cc +++ b/native_client_sdk/src/libraries/nacl_io/kernel_wrap_newlib.cc @@ -46,6 +46,7 @@ EXTERN_C_BEGIN __libnacl_irt_##group.name = (typeof(REAL(name)))WRAP(name); extern void __libnacl_irt_dev_filename_init(void); +extern void __libnacl_irt_dev_fdio_init(void); extern struct nacl_irt_basic __libnacl_irt_basic; extern struct nacl_irt_fdio __libnacl_irt_fdio; @@ -261,13 +262,14 @@ static void assign_real_pointers() { static bool assigned = false; if (!assigned) { __libnacl_irt_dev_filename_init(); + __libnacl_irt_dev_fdio_init(); EXPAND_SYMBOL_LIST_OPERATION(ASSIGN_REAL_PTR) assigned = true; } } -#define CHECK_REAL(func) \ - if (!REAL(func)) \ +#define CHECK_REAL(func) \ + if (!REAL(func)) \ assign_real_pointers(); // "real" functions, i.e. the unwrapped original functions. @@ -289,6 +291,12 @@ int _real_fstat(int fd, struct stat* buf) { int _real_isatty(int fd, int* result) { CHECK_REAL(isatty); + // The real isatty function can be NULL (for example if we are running + // withing chrome). + if (REAL(isatty) == NULL) { + *result = 0; + return ENOTTY; + } return REAL(isatty)(fd, result); } @@ -303,7 +311,8 @@ int _real_lseek(int fd, off_t offset, int whence, off_t* new_offset) { } int _real_mkdir(const char* pathname, mode_t mode) { - return ENOSYS; + CHECK_REAL(mkdir); + return REAL(mkdir)(pathname, mode); } int _real_mmap(void** addr, @@ -336,7 +345,8 @@ int _real_read(int fd, void* buf, size_t count, size_t* nread) { } int _real_rmdir(const char* pathname) { - return ENOSYS; + CHECK_REAL(rmdir); + return REAL(rmdir)(pathname); } int _real_write(int fd, const void* buf, size_t count, size_t* nwrote) { diff --git a/native_client_sdk/src/libraries/nacl_io/library.dsc b/native_client_sdk/src/libraries/nacl_io/library.dsc index 10dd17203a..95b0c864d5 100644 --- a/native_client_sdk/src/libraries/nacl_io/library.dsc +++ b/native_client_sdk/src/libraries/nacl_io/library.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['bionic', 'newlib', 'glibc', 'pnacl', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'linux'], 'SEARCH': [ '.', 'pepper', @@ -48,6 +48,7 @@ "nacl_io.cc", "node.cc", "passthroughfs/passthrough_fs.cc", + "passthroughfs/real_node.cc", "path.cc", "pepper_interface.cc", "pepper_interface_delegate.cc", @@ -72,18 +73,12 @@ "syscalls/cfsetispeed.c", "syscalls/cfsetospeed.c", "syscalls/cfsetspeed.c", - "syscalls/chdir.c", "syscalls/chmod.c", "syscalls/chown.c", "syscalls/connect.c", - "syscalls/fchdir.c", - "syscalls/fchmod.c", "syscalls/fchown.c", "syscalls/fcntl.c", - "syscalls/fdatasync.c", - "syscalls/fdopen.c", "syscalls/freeaddrinfo.c", - "syscalls/fsync.c", "syscalls/ftruncate.c", "syscalls/gai_strerror.c", "syscalls/getaddrinfo.c", @@ -109,8 +104,6 @@ "syscalls/lchown.c", "syscalls/link.c", "syscalls/listen.c", - "syscalls/lstat.c", - "syscalls/mkdir.c", # Not called mount.c to avoid object file naming conflict with # mount.cc. "syscalls/syscall_mount.c", @@ -118,14 +111,12 @@ "syscalls/ntohs.c", "syscalls/pipe.c", "syscalls/poll.c", - "syscalls/readlink.c", "syscalls/realpath.c", "syscalls/recv.c", "syscalls/recvfrom.c", "syscalls/recvmsg.c", "syscalls/remove.c", "syscalls/rename.c", - "syscalls/rmdir.c", "syscalls/select.c", "syscalls/send.c", "syscalls/sendmsg.c", @@ -133,11 +124,6 @@ "syscalls/setsockopt.c", "syscalls/shutdown.c", "syscalls/sigaction.c", - "syscalls/sigaddset.c", - "syscalls/sigdelset.c", - "syscalls/sigemptyset.c", - "syscalls/sigfillset.c", - "syscalls/sigismember.c", "syscalls/signal.c", "syscalls/sigpause.c", "syscalls/sigpending.c", @@ -157,7 +143,6 @@ "syscalls/uname.c", "syscalls/unlink.c", "syscalls/utime.c", - "syscalls/utimes.c", ], } ], @@ -213,6 +198,7 @@ "osunistd.h", "osutime.h", "passthroughfs/passthrough_fs.h", + "passthroughfs/real_node.h", "path.h", "pepper_interface_delegate.h", "pepper_interface_dummy.h", diff --git a/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.cc b/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.cc index 52c5f961f9..93dbf18672 100644 --- a/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.cc +++ b/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.cc @@ -8,120 +8,10 @@ #include "nacl_io/kernel_handle.h" #include "nacl_io/kernel_wrap_real.h" +#include "nacl_io/passthroughfs/real_node.h" namespace nacl_io { -class PassthroughFsNode : public Node { - public: - explicit PassthroughFsNode(Filesystem* filesystem, int real_fd) - : Node(filesystem), real_fd_(real_fd) {} - - protected: - virtual Error Init(int flags) { return 0; } - - virtual void Destroy() { - if (real_fd_) - _real_close(real_fd_); - real_fd_ = 0; - } - - public: - // Normal read/write operations on a file - virtual Error Read(const HandleAttr& attr, - void* buf, - size_t count, - int* out_bytes) { - *out_bytes = 0; - - int64_t new_offset; - int err = _real_lseek(real_fd_, attr.offs, 0, &new_offset); - if (err) - return err; - - size_t nread; - err = _real_read(real_fd_, buf, count, &nread); - if (err) - return err; - - *out_bytes = static_cast<int>(nread); - return 0; - } - - virtual Error Write(const HandleAttr& attr, - const void* buf, - size_t count, - int* out_bytes) { - *out_bytes = 0; - - int64_t new_offset; - int err = _real_lseek(real_fd_, attr.offs, 0, &new_offset); - if (err) - return err; - - size_t nwrote; - err = _real_write(real_fd_, buf, count, &nwrote); - if (err) - return err; - - *out_bytes = static_cast<int>(nwrote); - return 0; - } - - virtual Error FTruncate(off_t size) { - // TODO(binji): what to do here? - return ENOSYS; - } - - virtual Error GetDents(size_t offs, - struct dirent* pdir, - size_t count, - int* out_bytes) { - size_t nread; - int err = _real_getdents(real_fd_, pdir, count, &nread); - if (err) - return err; - return nread; - } - - virtual Error GetStat(struct stat* stat) { - int err = _real_fstat(real_fd_, stat); - if (err) - return err; - return 0; - } - - virtual Error Isatty() { -#ifdef __GLIBC__ - // isatty is not yet hooked up to the IRT interface under glibc. - return ENOTTY; -#else - int result = 0; - int err = _real_isatty(real_fd_, &result); - if (err) - return err; - return 0; -#endif - } - - Error MMap(void* addr, - size_t length, - int prot, - int flags, - size_t offset, - void** out_addr) { - *out_addr = addr; - int err = _real_mmap(out_addr, length, prot, flags, real_fd_, offset); - if (err) - return err; - return 0; - } - - private: - friend class PassthroughFs; - - int real_fd_; -}; - PassthroughFs::PassthroughFs() { } @@ -144,7 +34,7 @@ Error PassthroughFs::Open(const Path& path, int mode, ScopedNode* out_node) { if (error) return error; - out_node->reset(new PassthroughFsNode(this, real_fd)); + out_node->reset(new RealNode(this, real_fd, true)); return 0; } @@ -155,7 +45,7 @@ Error PassthroughFs::OpenResource(const Path& path, ScopedNode* out_node) { if (error) return error; - out_node->reset(new PassthroughFsNode(this, real_fd)); + out_node->reset(new RealNode(this, real_fd)); return 0; } diff --git a/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.h b/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.h index 498201bedf..a26ca7118d 100644 --- a/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.h +++ b/native_client_sdk/src/libraries/nacl_io/passthroughfs/passthrough_fs.h @@ -3,7 +3,6 @@ // found in the LICENSE file. #ifndef LIBRARIES_NACL_IO_PASSTHROUGHFS_PASSTHROUGH_FS_H_ - #define LIBRARIES_NACL_IO_PASSTHROUGHFS_PASSTHROUGH_FS_H_ #include "nacl_io/filesystem.h" diff --git a/native_client_sdk/src/libraries/nacl_io/passthroughfs/real_node.cc b/native_client_sdk/src/libraries/nacl_io/passthroughfs/real_node.cc new file mode 100644 index 0000000000..08a4e32ddc --- /dev/null +++ b/native_client_sdk/src/libraries/nacl_io/passthroughfs/real_node.cc @@ -0,0 +1,118 @@ +// Copyright 2014 The Chromium Authors. All rights reserved. +// Use of this source code is governed by a BSD-style license that can be +// found in the LICENSE file. + +#include "nacl_io/passthroughfs/real_node.h" + +#include <errno.h> + +#include "nacl_io/kernel_handle.h" +#include "nacl_io/kernel_wrap_real.h" + +namespace nacl_io { +RealNode::RealNode(Filesystem* filesystem, int real_fd, bool close_on_destroy) + : Node(filesystem), + real_fd_(real_fd), + close_on_destroy_(close_on_destroy) +{ +} + +void RealNode::Destroy() { + if (close_on_destroy_) + _real_close(real_fd_); + real_fd_ = -1; +} + +// Normal read/write operations on a file +Error RealNode::Read(const HandleAttr& attr, + void* buf, + size_t count, + int* out_bytes) { + *out_bytes = 0; + + int64_t new_offset; + int err = _real_lseek(real_fd_, attr.offs, 0, &new_offset); + if (err && err != ESPIPE) + return err; + + size_t nread; + err = _real_read(real_fd_, buf, count, &nread); + if (err) + return err; + + *out_bytes = static_cast<int>(nread); + return 0; +} + +Error RealNode::Write(const HandleAttr& attr, + const void* buf, + size_t count, + int* out_bytes) { + //nacl_io_log("Real::Write\n"); + int err; + *out_bytes = 0; + + int64_t new_offset; + err = _real_lseek(real_fd_, attr.offs, 0, &new_offset); + if (err && err != ESPIPE) + return err; + + size_t nwrote; + err = _real_write(real_fd_, buf, count, &nwrote); + if (err) + return err; + + *out_bytes = static_cast<int>(nwrote); + return 0; +} + +Error RealNode::FTruncate(off_t size) { + // TODO(binji): what to do here? + return ENOSYS; +} + +Error RealNode::GetDents(size_t offs, + struct dirent* pdir, + size_t count, + int* out_bytes) { + size_t nread; + int err = _real_getdents(real_fd_, pdir, count, &nread); + if (err) + return err; + return nread; +} + +Error RealNode::GetStat(struct stat* stat) { + int err = _real_fstat(real_fd_, stat); + if (err) + return err; + return 0; +} + +Error RealNode::Isatty() { +#ifdef __GLIBC__ + // isatty is not yet hooked up to the IRT interface under glibc. + return ENOTTY; +#else + int result = 0; + int err = _real_isatty(real_fd_, &result); + if (err) + return err; + return 0; +#endif +} + +Error RealNode::MMap(void* addr, + size_t length, + int prot, + int flags, + size_t offset, + void** out_addr) { + *out_addr = addr; + int err = _real_mmap(out_addr, length, prot, flags, real_fd_, offset); + if (err) + return err; + return 0; +} + +} diff --git a/native_client_sdk/src/libraries/nacl_io/passthroughfs/real_node.h b/native_client_sdk/src/libraries/nacl_io/passthroughfs/real_node.h new file mode 100644 index 0000000000..2bc3ac184c --- /dev/null +++ b/native_client_sdk/src/libraries/nacl_io/passthroughfs/real_node.h @@ -0,0 +1,52 @@ +// Copyright 2014 The Chromium Authors. All rights reserved. +// Use of this source code is governed by a BSD-style license that can be +// found in the LICENSE file. +// +#ifndef LIBRARIES_NACL_IO_PASSTHROUGHFS_REAL_NODE_H_ +#define LIBRARIES_NACL_IO_PASSTHROUGHFS_REAL_NODE_H_ + +#include "nacl_io/node.h" + +namespace nacl_io { + +class RealNode : public Node { + public: + RealNode(Filesystem* filesystem, int real_fd, bool close_on_destroy = false); + + protected: + virtual Error Init(int flags) { return 0; } + + virtual void Destroy(); + + public: + // Normal read/write operations on a file + virtual Error Read(const HandleAttr& attr, + void* buf, + size_t count, + int* out_bytes); + virtual Error Write(const HandleAttr& attr, + const void* buf, + size_t count, + int* out_bytes); + virtual Error FTruncate(off_t size); + virtual Error GetDents(size_t offs, + struct dirent* pdir, + size_t count, + int* out_bytes); + virtual Error GetStat(struct stat* stat); + virtual Error Isatty(); + virtual Error MMap(void* addr, + size_t length, + int prot, + int flags, + size_t offset, + void** out_addr); + + private: + int real_fd_; + bool close_on_destroy_; +}; + +} // namespace nacl_io + +#endif // LIBRARIES_NACL_IO_PASSTHROUGHFS_REAL_NODE_H_ diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/access.c b/native_client_sdk/src/libraries/nacl_io/syscalls/access.c index 6c94ac2c1f..62e9e20df8 100644 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/access.c +++ b/native_client_sdk/src/libraries/nacl_io/syscalls/access.c @@ -5,9 +5,8 @@ #include "nacl_io/kernel_intercept.h" #include "nacl_io/kernel_wrap.h" -#if !defined(__native_client__) || defined(__GLIBC__) || defined(__BIONIC__) -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 +#if defined(__BIONIC__) +// Bionic only int access(const char* path, int amode) { return ki_access(path, amode); } diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/chdir.c b/native_client_sdk/src/libraries/nacl_io/syscalls/chdir.c deleted file mode 100644 index a7d5c9d7f7..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/chdir.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) && defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int chdir(const char* path) { - return ki_chdir(path); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/fchdir.c b/native_client_sdk/src/libraries/nacl_io/syscalls/fchdir.c deleted file mode 100644 index 816313152e..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/fchdir.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int fchdir(int fd) { - return ki_fchdir(fd); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/fchmod.c b/native_client_sdk/src/libraries/nacl_io/syscalls/fchmod.c deleted file mode 100644 index c1fe254b72..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/fchmod.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int fchmod(int fd, mode_t mode) { - return ki_fchmod(fd, mode); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/fdatasync.c b/native_client_sdk/src/libraries/nacl_io/syscalls/fdatasync.c deleted file mode 100644 index 1606fcf1b0..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/fdatasync.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int fdatasync(int fd) { - return ki_fdatasync(fd); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/fdopen.c b/native_client_sdk/src/libraries/nacl_io/syscalls/fdopen.c deleted file mode 100644 index 744922298c..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/fdopen.c +++ /dev/null @@ -1,52 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#ifndef _GNU_SOURCE -#define _GNU_SOURCE -#endif -#include <stdio.h> -#include <sys/types.h> -#include <unistd.h> - -#if defined(__native_client__) && defined(__GLIBC__) - -static ssize_t fdopen_read(void *cookie, char *buf, size_t size) { - return read((int) cookie, buf, size); -} - -static ssize_t fdopen_write(void *cookie, const char *buf, size_t size) { - return write((int) cookie, buf, size); -} - -static int fdopen_seek(void *cookie, off_t *offset, int whence) { - off_t ret = lseek((int) cookie, *offset, whence); - if (ret < 0) { - return -1; - } - *offset = ret; - return 0; -} - -static int fdopen_close(void *cookie) { - return close((int) cookie); -} - -static cookie_io_functions_t fdopen_functions = { - fdopen_read, - fdopen_write, - fdopen_seek, - fdopen_close, -}; - -/* - * TODO(bradnelson): Remove this glibc is fixed. - * See: https://code.google.com/p/nativeclient/issues/detail?id=3362 - * Workaround fdopen in glibc failing due to it vetting the provided file - * handles with fcntl which is not currently interceptable. - */ -FILE *fdopen(int fildes, const char *mode) { - return fopencookie((void *) fildes, mode, fdopen_functions); -} - -#endif /* defined(__native_client__) && defined(__GLIBC__) */ diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/fsync.c b/native_client_sdk/src/libraries/nacl_io/syscalls/fsync.c deleted file mode 100644 index 106d137b68..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/fsync.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int fsync(int fd) { - return ki_fsync(fd); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/getcwd.c b/native_client_sdk/src/libraries/nacl_io/syscalls/getcwd.c index aff35d8544..5e702ca381 100644 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/getcwd.c +++ b/native_client_sdk/src/libraries/nacl_io/syscalls/getcwd.c @@ -8,6 +8,12 @@ #include "nacl_io/kernel_intercept.h" #include "nacl_io/kernel_wrap.h" +/* + * This interception should not really be needed under glibc since we can + * hook the internal calls to getcwd. However, we need to intercept it here + * since gtest call getcwd in a static constructor which general runs before + * nacl_io is initiliased. + */ char* getcwd(char* buf, size_t size) { // If size is 0, allocate as much as we need. if (size == 0) { diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/lstat.c b/native_client_sdk/src/libraries/nacl_io/syscalls/lstat.c deleted file mode 100644 index 0174f418c2..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/lstat.c +++ /dev/null @@ -1,18 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 - -// In release builds glibc will inline calls to lstat to the -// lower level __lxstat, so we intercept that call instead. -int __lxstat(int ver, const char* pathname, struct stat* buf) { - return ki_lstat(pathname, buf); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/mkdir.c b/native_client_sdk/src/libraries/nacl_io/syscalls/mkdir.c deleted file mode 100644 index cecaa3d076..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/mkdir.c +++ /dev/null @@ -1,16 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) -// Don't wrap mkdir on host builds. This allows us to test against the real -// "mkdir" on Linux standalone builds. - -int mkdir(const char* pathname, mode_t mode) { - return ki_mkdir(pathname, mode); -} - -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/readlink.c b/native_client_sdk/src/libraries/nacl_io/syscalls/readlink.c deleted file mode 100644 index 431f8be6dd..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/readlink.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int readlink(const char* pathname, char* buf, int len) { - return ki_readlink(pathname, buf, len); -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/rmdir.c b/native_client_sdk/src/libraries/nacl_io/syscalls/rmdir.c deleted file mode 100644 index 35c62db673..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/rmdir.c +++ /dev/null @@ -1,10 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -int rmdir(const char* path) { - return ki_rmdir(path); -} diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/sigaddset.c b/native_client_sdk/src/libraries/nacl_io/syscalls/sigaddset.c deleted file mode 100644 index e3df654a62..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/sigaddset.c +++ /dev/null @@ -1,13 +0,0 @@ -/* Copyright 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) && !defined(__GLIBC__) && !defined(__BIONIC__) -int sigaddset(sigset_t* set, const int signum) { - *set |= (1 << signum); - return 0; -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/sigdelset.c b/native_client_sdk/src/libraries/nacl_io/syscalls/sigdelset.c deleted file mode 100644 index b595320fc9..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/sigdelset.c +++ /dev/null @@ -1,13 +0,0 @@ -/* Copyright 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) && !defined(__GLIBC__) && !defined(__BIONIC__) -int sigdelset(sigset_t* set, const int signum) { - *set &= ~(1 << signum); - return 0; -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/sigemptyset.c b/native_client_sdk/src/libraries/nacl_io/syscalls/sigemptyset.c deleted file mode 100644 index 834509c1d9..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/sigemptyset.c +++ /dev/null @@ -1,13 +0,0 @@ -/* Copyright 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) && !defined(__GLIBC__) && !defined(__BIONIC__) -int sigemptyset(sigset_t* set) { - *set = 0; - return 0; -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/sigfillset.c b/native_client_sdk/src/libraries/nacl_io/syscalls/sigfillset.c deleted file mode 100644 index 0964ee681e..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/sigfillset.c +++ /dev/null @@ -1,13 +0,0 @@ -/* Copyright 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) && !defined(__GLIBC__) && !defined(__BIONIC__) -int sigfillset(sigset_t* set) { - *set = ~0; - return 0; -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/sigismember.c b/native_client_sdk/src/libraries/nacl_io/syscalls/sigismember.c deleted file mode 100644 index 6a3218390d..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/sigismember.c +++ /dev/null @@ -1,12 +0,0 @@ -/* Copyright 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if defined(__native_client__) && !defined(__GLIBC__) && !defined(__BIONIC__) -int sigismember(const sigset_t* set, int signum) { - return (*set & (1 << signum)) != 0; -} -#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/unlink.c b/native_client_sdk/src/libraries/nacl_io/syscalls/unlink.c index 3ee6af6579..e539a91ef4 100644 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/unlink.c +++ b/native_client_sdk/src/libraries/nacl_io/syscalls/unlink.c @@ -5,6 +5,8 @@ #include "nacl_io/kernel_intercept.h" #include "nacl_io/kernel_wrap.h" +#ifndef __GLIBC__ int unlink(const char* path) { return ki_unlink(path); } +#endif diff --git a/native_client_sdk/src/libraries/nacl_io/syscalls/utimes.c b/native_client_sdk/src/libraries/nacl_io/syscalls/utimes.c deleted file mode 100644 index 604fef55f8..0000000000 --- a/native_client_sdk/src/libraries/nacl_io/syscalls/utimes.c +++ /dev/null @@ -1,15 +0,0 @@ -/* Copyright (c) 2013 The Chromium Authors. All rights reserved. - * Use of this source code is governed by a BSD-style license that can be - * found in the LICENSE file. */ - -#include "nacl_io/kernel_intercept.h" -#include "nacl_io/kernel_wrap.h" - -#if !defined(__native_client__) || defined(__GLIBC__) -// GLIBC-only entry point. -// TODO(sbc): remove once this bug gets fixed: -// https://code.google.com/p/nativeclient/issues/detail?id=3709 -int utimes(const char* filename, const struct timeval times[2]) { - return ki_utimes(filename, times); -} -#endif diff --git a/native_client_sdk/src/libraries/ppapi_cpp/library.dsc b/native_client_sdk/src/libraries/ppapi_cpp/library.dsc index bb3d032b26..1ca014e6c2 100644 --- a/native_client_sdk/src/libraries/ppapi_cpp/library.dsc +++ b/native_client_sdk/src/libraries/ppapi_cpp/library.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['bionic', 'newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'SEARCH': [ '../../../../ppapi/cpp', '../../../../ppapi/cpp/dev', diff --git a/native_client_sdk/src/libraries/ppapi_cpp_private/library.dsc b/native_client_sdk/src/libraries/ppapi_cpp_private/library.dsc index 02817ac97d..33e64e24b6 100644 --- a/native_client_sdk/src/libraries/ppapi_cpp_private/library.dsc +++ b/native_client_sdk/src/libraries/ppapi_cpp_private/library.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'SEARCH': [ '../../../../ppapi/c/private', '../../../../ppapi/cpp/private', diff --git a/native_client_sdk/src/libraries/ppapi_gles2/library.dsc b/native_client_sdk/src/libraries/ppapi_gles2/library.dsc index 6b8b21e29b..aaf19c942a 100644 --- a/native_client_sdk/src/libraries/ppapi_gles2/library.dsc +++ b/native_client_sdk/src/libraries/ppapi_gles2/library.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['bionic', 'newlib', 'glibc', 'pnacl', 'linux', 'win'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'linux', 'win'], 'SEARCH' : [ '../../../../ppapi/lib/gl/gles2', '../../../../ppapi/lib/gl/include/EGL', diff --git a/native_client_sdk/src/libraries/sdk_util/library.dsc b/native_client_sdk/src/libraries/sdk_util/library.dsc index 961a43f3dd..1ec8b3c03e 100644 --- a/native_client_sdk/src/libraries/sdk_util/library.dsc +++ b/native_client_sdk/src/libraries/sdk_util/library.dsc @@ -1,5 +1,5 @@ { - 'TOOLS': ['bionic', 'newlib', 'glibc', 'pnacl', 'win', 'linux'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'pnacl', 'win', 'linux'], 'TARGETS': [ { 'NAME' : 'sdk_util', diff --git a/native_client_sdk/src/libraries/zlib/library.dsc b/native_client_sdk/src/libraries/zlib/library.dsc index d7409e9730..422e01344e 100644 --- a/native_client_sdk/src/libraries/zlib/library.dsc +++ b/native_client_sdk/src/libraries/zlib/library.dsc @@ -1,6 +1,6 @@ { 'DISABLE': True, - 'TOOLS': ['bionic', 'newlib', 'glibc', 'linux', 'win'], + 'TOOLS': ['newlib', 'glibc', 'bionic', 'linux', 'win'], 'SEARCH': [ '../../../../third_party/zlib', ], diff --git a/native_client_sdk/src/tests/nacl_io_socket_test/example.dsc b/native_client_sdk/src/tests/nacl_io_socket_test/example.dsc index 98f58f59a6..40862cfc52 100644 --- a/native_client_sdk/src/tests/nacl_io_socket_test/example.dsc +++ b/native_client_sdk/src/tests/nacl_io_socket_test/example.dsc @@ -13,7 +13,7 @@ 'DEPS': ['ppapi_simple', 'nacl_io'], # Order matters here: gtest has a "main" function that will be used if # referenced before ppapi. - 'LIBS': ['ppapi_simple', 'gmock', 'nacl_io', 'ppapi_cpp', 'ppapi', 'gtest', 'pthread'], + 'LIBS': ['ppapi_simple', 'gmock', 'ppapi', 'gtest', 'nacl_io', 'ppapi_cpp', 'pthread'], 'CXXFLAGS': ['-Wno-sign-compare'] } ], diff --git a/native_client_sdk/src/tests/nacl_io_test/example.dsc b/native_client_sdk/src/tests/nacl_io_test/example.dsc index ecfd0131b4..6fac671431 100644 --- a/native_client_sdk/src/tests/nacl_io_test/example.dsc +++ b/native_client_sdk/src/tests/nacl_io_test/example.dsc @@ -64,7 +64,7 @@ 'DEPS': ['ppapi_simple', 'nacl_io'], # Order matters here: gtest has a "main" function that will be used if # referenced before ppapi. - 'LIBS': ['ppapi_simple', 'gmock', 'nacl_io', 'ppapi_cpp', 'ppapi', 'gtest', 'pthread'], + 'LIBS': ['ppapi_simple', 'gmock', 'nacl_io', 'ppapi', 'gtest', 'ppapi_cpp', 'pthread'], 'INCLUDES': ["."], 'CXXFLAGS': ['-Wno-sign-compare'], } diff --git a/native_client_sdk/src/tests/nacl_io_test/kernel_wrap_test.cc b/native_client_sdk/src/tests/nacl_io_test/kernel_wrap_test.cc index 5dc4f13455..9b03b5a483 100644 --- a/native_client_sdk/src/tests/nacl_io_test/kernel_wrap_test.cc +++ b/native_client_sdk/src/tests/nacl_io_test/kernel_wrap_test.cc @@ -68,6 +68,10 @@ ACTION_P(SetErrno, value) { errno = value; } +ACTION_P2(SetString, target, source) { + strcpy(target, source); +} + ACTION_P(SetStat, statbuf) { memset(arg1, 0, sizeof(struct stat)); arg1->st_dev = statbuf->st_dev; @@ -296,10 +300,13 @@ TEST_F(KernelWrapTest, fsync) { } TEST_F(KernelWrapTest, getcwd) { - char result[] = "getcwd_result"; - char buffer[] = "getcwd"; - EXPECT_CALL(mock, getcwd(buffer, kDummySizeT)).WillOnce(Return(result)); - EXPECT_EQ(result, getcwd(buffer, kDummySizeT)); + char buffer[PATH_MAX]; + char result[PATH_MAX]; + memset(buffer, 0, PATH_MAX); + strcpy(result, "getcwd_result"); + EXPECT_CALL(mock, getcwd(buffer, kDummySizeT)) + .WillOnce(DoAll(SetString(buffer, result), Return(buffer))); + EXPECT_STREQ(result, getcwd(buffer, kDummySizeT)); } TEST_F(KernelWrapTest, getdents) { @@ -381,8 +388,9 @@ TEST_F(KernelWrapTest, mkdir) { EXPECT_EQ(kDummyInt2, mkdir(kDummyConstChar)); #else EXPECT_CALL(mock, mkdir(kDummyConstChar, kDummyMode)) - .WillOnce(Return(kDummyInt2)); - EXPECT_EQ(kDummyInt2, mkdir(kDummyConstChar, kDummyMode)); + .WillOnce(DoAll(SetErrno(kDummyErrno), Return(-1))); + EXPECT_EQ(-1, mkdir(kDummyConstChar, kDummyMode)); + ASSERT_EQ(kDummyErrno, errno); #endif } @@ -492,8 +500,10 @@ TEST_F(KernelWrapTest, rename) { } TEST_F(KernelWrapTest, rmdir) { - EXPECT_CALL(mock, rmdir(kDummyConstChar)).WillOnce(Return(kDummyInt)); - EXPECT_EQ(kDummyInt, rmdir(kDummyConstChar)); + EXPECT_CALL(mock, rmdir(kDummyConstChar)) + .WillOnce(DoAll(SetErrno(kDummyErrno), Return(-1))); + EXPECT_EQ(-1, rmdir(kDummyConstChar)); + ASSERT_EQ(kDummyErrno, errno); } static void new_handler(int) {} @@ -594,8 +604,10 @@ TEST_F(KernelWrapTest, lstat) { } TEST_F(KernelWrapTest, unlink) { - EXPECT_CALL(mock, unlink(kDummyConstChar)).WillOnce(Return(kDummyInt)); - EXPECT_EQ(kDummyInt, unlink(kDummyConstChar)); + EXPECT_CALL(mock, unlink(kDummyConstChar)) + .WillOnce(DoAll(SetErrno(kDummyErrno), Return(-1))); + EXPECT_EQ(-1, unlink(kDummyConstChar)); + ASSERT_EQ(kDummyErrno, errno); } TEST_F(KernelWrapTest, utime) { diff --git a/native_client_sdk/src/tests/sdk_util_test/example.dsc b/native_client_sdk/src/tests/sdk_util_test/example.dsc index 17d2cf7e4a..91e9df4dda 100644 --- a/native_client_sdk/src/tests/sdk_util_test/example.dsc +++ b/native_client_sdk/src/tests/sdk_util_test/example.dsc @@ -13,7 +13,7 @@ 'DEPS': ['ppapi_simple', 'sdk_util', 'nacl_io'], # Order matters here: gtest has a "main" function that will be used if # referenced before ppapi. - 'LIBS': ['ppapi_simple', 'sdk_util', 'nacl_io', 'gmock', 'ppapi_cpp', 'ppapi', 'gtest', 'pthread'], + 'LIBS': ['ppapi_simple', 'sdk_util', 'ppapi', 'gtest', 'nacl_io', 'gmock', 'ppapi_cpp', 'pthread'], 'CXXFLAGS': ['-Wno-sign-compare'] } ], diff --git a/native_client_sdk/src/tools/getos.py b/native_client_sdk/src/tools/getos.py index 89b6c57900..c4e31c3188 100755 --- a/native_client_sdk/src/tools/getos.py +++ b/native_client_sdk/src/tools/getos.py @@ -144,9 +144,17 @@ def GetNaClArch(platform): # If CHROME_PATH is set to point to google-chrome or google-chrome # was found in the PATH and we are running on UNIX then google-chrome # is a bash script that points to 'chrome' in the same folder. - if os.path.basename(chrome_path) == 'google-chrome': + # + # When running beta or dev branch, the name is google-chrome-{beta,dev}. + if os.path.basename(chrome_path).startswith('google-chrome'): chrome_path = os.path.join(os.path.dirname(chrome_path), 'chrome') + if not os.path.exists(chrome_path): + raise Error("File %s does not exist." % chrome_path) + + if not os.access(chrome_path, os.X_OK): + raise Error("File %s is not executable" % chrome_path) + try: pobj = subprocess.Popen(['objdump', '-f', chrome_path], stdout=subprocess.PIPE, |