LLParser: add an argument for overriding data layout and do not check alloca addr space

[yaxunl]

Summary

Sometimes users do not specify data layout in LLVM assembly and let llc set the data layout by target triple after loading the LLVM assembly.

Currently the parser checks alloca address space no matter whether the LLVM assembly contains data layout definition, which causes false alarm since the default data layout does not contain the correct alloca address space.

The parser also calls verifier to check debug info and updating invalid debug info. Currently there is no way to let the verifier to check debug info only. If the verifier finds non-debug-info issues the parser will fail.

For llc, the fix is to remove the check of alloca addr space in the parser and disable updating debug info, and defer the updating of debug info and verification to be after setting data layout of the IR by target.

For other llvm tools, since they do not override data layout by target but instead can override data layout by a command line option, an argument for overriding data layout is added to the parser. In cases where data layout overriding is necessary for the parser, the data layout can be provided by command line.

[arsenm]

lib/AsmParser/LLParser.cpp

6181–6185 ↗

(On Diff #128967)

The idea was to remove this check from the parser entirely

lib/IR/Verifier.cpp

3210 ↗

(On Diff #128967)

s/stack/DataLayout alloca/

[yaxunl]

lib/AsmParser/LLParser.cpp

6181–6185 ↗

(On Diff #128967)

Removing this check will cause some lit tests to fail since the verifier output different error messages.

The error message from the parser is better since it contains line/column number. Should we keep the check if the assembly contains data layout definition?

lib/IR/Verifier.cpp

3210 ↗

(On Diff #128967)

will fix.

[arsenm]

lib/AsmParser/LLParser.cpp

6181–6185 ↗

(On Diff #128967)

I think that's less important. The verifier error will dump the instruction so it's not difficult to find anyway. I think changing the error depending on whether the datalayout is in the module already would be inconsistent

[yaxunl]

lib/AsmParser/LLParser.cpp

6181–6185 ↗

(On Diff #128967)

OK. Will remove this and update lit tests.

[yaxunl]

Removed check of alloca addr space from LLParser.

[arsenm]

include/llvm/IR/Verifier.h

101 ↗

(On Diff #128971)

I'm not sure I understand why this option is needed or to UpgradeDebugInfo. I would expect the datalayout to be set already by the time any verification is done

[yaxunl]

include/llvm/IR/Verifier.h

101 ↗

(On Diff #128971)

LLParser calls UpgradeDebugInfo, which calls verifyModule. At this point the datalayout has not been set yet. llc sets datalayout by target after parsing the IR.

[arsenm]

include/llvm/IR/Verifier.h

101 ↗

(On Diff #128971)

Why does UpgradeDebugInfo need a special second verify run? Is there an issue with just removing that and relying on the normal verify pass?

[yaxunl]

include/llvm/IR/Verifier.h

101 ↗

(On Diff #128971)

UpgradeDebugInfo checks if the module only contains debug info error or any other error. If the module only contains debug info error, then it reports the error. If the debug info version is outdated, it deletes the debug info. If the module contains other error, it will report fatal error.

LLParser calls UpgradeDebugInfo mainly to report debug info error and delete outdated debug info. However since UpgradeDeugInfo may be called by other functions which expect it to abort on invalid module.

[yaxunl]

Removed module verification from UpgradeDebugInfo. UpgradeDebugInfo only checks debug info.

[yaxunl]

include/llvm/IR/Verifier.h

101 ↗

(On Diff #128971)

I have updated the patch so that UpgradeDebugInfo only checks debug info. It still needs to check debug info because it needs to delete invalid debug info. Now it does not check non-debug-info issues. Please take a look. Thanks.

[yaxunl]

ping

[arsenm]

lib/IR/Verifier.cpp

214–216 ↗

(On Diff #129499)

This seems to just be stopping all error messages?

test/Verifier/llvm.dbg.intrinsic-dbg-attachment.ll

1 ↗

(On Diff #129499)

This is a test regression

[yaxunl]

lib/IR/Verifier.cpp

214–216 ↗

(On Diff #129499)

No. This will only stop checking of non-debug info and will not stop checking debug info. Since checking of debug info does not use this function but uses DebugInfoCheckFailed.

test/Verifier/llvm.dbg.intrinsic-dbg-attachment.ll

1 ↗

(On Diff #129499)

This test should pass since it only contains invalid debug info. After the parser removes the debug info, the IR is valid. There is a bug in verifier mistakenly treated debug info error as non-debug info error. (See change in Verifier.cpp line 4492 for the fix). After that bug is fixed, this test should pass.

[arsenm]

test/Verifier/llvm.dbg.intrinsic-dbg-attachment.ll

1 ↗

(On Diff #129499)

Can you fix this in a separate patch then?

[yaxunl]

test/Verifier/llvm.dbg.intrinsic-dbg-attachment.ll

1 ↗

(On Diff #129499)

will do.

[yaxunl]

test/Verifier/llvm.dbg.intrinsic-dbg-attachment.ll

1 ↗

(On Diff #129499)

Separated the fix to https://reviews.llvm.org/D42391

[yaxunl]

Separated a bug fix about verifier incorrectly treating debug info error as non-debug-info error to another review.

[yaxunl]

Add a command line option to llvm-as to allow set datalayout. Opt already has such option but has a bug. Fixed the bug so that it works properly.
Add lit tests for llvm-as/opt.

[yaxunl]

Add back a change dropped by accident.

[aprantl]

lib/IR/Verifier.cpp

3239 ↗

(On Diff #131362)

Please move this change into a separate review, it looks like an orthogonal change and just makes this patch harder to understand.

214–216 ↗

(On Diff #129499)

Can you please elaborate on this? I'm afraid I didn't understand your explanation.

[yaxunl]

lib/IR/Verifier.cpp

3239 ↗

(On Diff #131362)

will do.

214–216 ↗

(On Diff #129499)

The verifier checks two types of issues:

1. debug info issues

2. non-debug info issues

with this change, when TreatBrokenDebugInfoAsError is set, the verifier will ignore non-debug-info issues and only check debug info issues.

This is necessary for LLParser. Because LLParser only wants to check debug info issues so that it can drop invalid debug info.

Checking of non-debug-info issues is deferred after parsing.

[yaxunl]

Separate the diagnostic error message change to https://reviews.llvm.org/D42543

[aprantl]

lib/IR/Verifier.cpp

214–216 ↗

(On Diff #129499)

In what situation would LLParser want to not verify the non-metadata part of the IR?

[aprantl]

I think I need some more context here. Is it accurate description that you want to be able to have LLParser accept malformed/underspecified address spaces on allocas? Why do you want to do this? Is this for writing testcases only? Both llc and opt already take an option to disable the verifier for the purpose of writing testcases. Why does this not work for you?

[aprantl]

Note that in production environments (think: non-asserts builds of LLVM) we *always* want/must run the verifier on any external input. This is very important for correctness and even for security (imagine LLVM as a JIT compiler for example).

[arsenm]

In D41832#988124, @aprantl wrote:

I think I need some more context here. Is it accurate description that you want to be able to have LLParser accept malformed/underspecified address spaces on allocas? Why do you want to do this? Is this for writing testcases only? Both llc and opt already take an option to disable the verifier for the purpose of writing testcases. Why does this not work for you?

The problem is tools like llc/opt can set the triple/datalayout from the command line. The parser is only capable of validating based on whatever IR is in the parsed module, so there is an inconsistency in what is considered valid IR until the datalayout is set. The verifier needs to be run as a separate step from the parsing, so clients would need to be responsible for running the verifier after it's set the datalayout. This is an issue for any datalayout dependent properties checked by the verifier, which as far as I can tell today is the alloca address space, and non-integral pointer address spaces.

[aprantl]

It sounds like what we really want is a --disable-datalayout-verification option that specifically just disables that one check?

[arsenm]

In D41832#988150, @aprantl wrote:

It sounds like what we really want is a --disable-datalayout-verification option that specifically just disables that one check?

I don't think this should be an option. We want the tools to work correctly with the verifier without manual intervention. Alternatively the parser should accept the datalayout and ignore whatever is parsed in the module?

[aprantl]

You are saying that if a datalayout is specified on the command line, it should override what is in the file? That sounds very reasonable to me.

[arsenm]

In D41832#988192, @aprantl wrote:

You are saying that if a datalayout is specified on the command line, it should override what is in the file? That sounds very reasonable to me.

Yes. I think an earlier version of the patch did something like that, but it seemed cleaner to me to separate the verifier from the initial IR parsing

[aprantl]

Wouldn't it be better to move the M->setDataLayout(ClDataLayout); to before we run the Verifier? It seems like we should verify the module in the state that it will be eventually consumed.

[yaxunl]

Can we reach consensus on how to fix this issue?

Letting LLParser accept an optional datalayout parameter and use it to override the datalayout in LLVM IR is simpler and more straightforward. There will be no change in Verifier.

[yaxunl]

In D41832#988209, @aprantl wrote:

Wouldn't it be better to move the M->setDataLayout(ClDataLayout); to before we run the Verifier? It seems like we should verify the module in the state that it will be eventually consumed.

Doing that solely is not enough for fixing the issue, since LLParser already calls Verifier before that by itself. Unless we provide LLParser a correct datalayout to override the datalayout from the IR, the verification inside the LLParser itself will still fail.

[aprantl]

LLParser already calls Verifier before that by itself

I wonder if that is actually necessary. Are there any code paths that invoke LLParser and don't run the Verifier afterwards? If not, then it would make sense to change that.

[yaxunl]

In D41832#988226, @aprantl wrote:

LLParser already calls Verifier before that by itself

I wonder if that is actually necessary. Are there any code paths that invoke LLParser and don't run the Verifier afterwards? If not, then it would make sense to change that.

There are some llvm tools invoke LLParser but do not run the Verifier afterwards, e.g. lli, llvm-cat, llvm-diff, etc.

[aprantl]

Thanks for checking!

Based on this, we could either

• make it the responsibility of the Caller of LLParser to run the Verifier and update those tools to run the Verifier.
• or pass the override datalayout into LLParser so it can inject it before running the Verifier.

I personally don't like the idea of relaxing the Verifier / making it verify something that is not what is being fed into the later stages. (Feel free to try and convince me otherwise though :-)

[yaxunl]

In D41832#988288, @aprantl wrote:

Thanks for checking!

Based on this, we could either

• make it the responsibility of the Caller of LLParser to run the Verifier and update those tools to run the Verifier.
• or pass the override datalayout into LLParser so it can inject it before running the Verifier.

I personally don't like the idea of relaxing the Verifier / making it verify something that is not what is being fed into the later stages. (Feel free to try and convince me otherwise though :-)

If we don't want to modify Verifier, then the only choice is to add an option to LLParser to allow datalayout to be overridden. Then the verifier will see a valid IR.

By adding the option to LLParser, all the tools automatically get an option to override the datalayout, then minimal change is needed.

[yaxunl]

I tried to add a parameter to LLParser for overriding datalayout. However I encountered another issue for llc.

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.

It seems we have to go back the current approach, that is, let LLParser only checks debug info and ignores non-debug info. For those llvm tools which does not explicitly verify module after parsing, I can add explicit verification after parsing.

[aprantl]

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.
It seems we have to go back the current approach, that is, let LLParser only checks debug info and ignores non-debug info. For those llvm tools which does not explicitly verify module after parsing, I can add explicit verification after parsing.

What about the other option: Don't run the verifier in LLParser and instead ensure that every client of LLParser runs the verifier?
We could even have the LLParser return a wrapper akin to

class UnverifiedModule {
  Module *M;
public:
  Module *verify();
}

to force clients to verify.

[yaxunl]

In D41832#989171, @aprantl wrote:

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.
It seems we have to go back the current approach, that is, let LLParser only checks debug info and ignores non-debug info. For those llvm tools which does not explicitly verify module after parsing, I can add explicit verification after parsing.

What about the other option: Don't run the verifier in LLParser and instead ensure that every client of LLParser runs the verifier?
We could even have the LLParser return a wrapper akin to

class UnverifiedModule {
  Module *M;
public:
  Module *verify();
}

to force clients to verify.

The parser needs to drop the invalid debug info. To do that it needs to call the verifier to check whether the debug info is valid. Do we also want to move dropping invalid debug info out of parser?

[aprantl]

You are right. My mental model of how this works was a bit out of date. We separated verification and debug info stripping recently. Let's scrap that idea.

Let's go back to your previous statement:

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.

Can you elaborate this? The problem is when only a datalayout but no target is specified on the commandline? Could you pass the datalayout as a string and have LLParser parse it?

[yaxunl]

In D41832#989179, @aprantl wrote:

You are right. My mental model of how this works was a bit out of date. We separated verification and debug info stripping recently. Let's scrap that idea.

Let's go back to your previous statement:

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.

Can you elaborate this? The problem is when only a datalayout but no target is specified on the commandline? Could you pass the datalayout as a string and have LLParser parse it?

llc is different from opt or llvm-as beause llc always override the datalayout of the input module with the datalayout of the target. Because llc always creates TargetMachine, it knows the datalayout string by target. Therefore llc is not supposed to get datalayout string by command line option. Instead, it is supposed to get datalayout string by target.

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

Of course, if we specify datalayout string by a command line option we can bypass this issue. If this does not sounds like a redundant option.

[aprantl]

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

I'm probably missing something obvious here. The case where llc gets invoked without a target on the command line must be working today, doesn't it? Why can't we fall back to that code path?

[yaxunl]

In D41832#989354, @aprantl wrote:

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

I'm probably missing something obvious here. The case where llc gets invoked without a target on the command line must be working today, doesn't it? Why can't we fall back to that code path?

This patch is trying to let llc load an llvm module which does not contain datalayout. In most cases, the parser is able to do that even though there is no datalayout in the module.

However, in some rare cases, the parser needs to know the datalayout to be able to parse the module. Therefore we discussed and concluded that we need to inject datalayout when parsing the module.

Let's consider the situation where llc command line does not contain target.

The old code path just parses the LLVM assembly and gets the target from the assembly. It can do that because it does not need to inject the datalayout.

However, now we need to inject datalayout when parsing, then we cannot since we don't know datalayout unless we parse the module to know the target first.

[yaxunl]

In D41832#989406, @yaxunl wrote:

In D41832#989354, @aprantl wrote:

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

I'm probably missing something obvious here. The case where llc gets invoked without a target on the command line must be working today, doesn't it? Why can't we fall back to that code path?

This patch is trying to let llc load an llvm module which does not contain datalayout. In most cases, the parser is able to do that even though there is no datalayout in the module.

However, in some rare cases, the parser needs to know the datalayout to be able to parse the module. Therefore we discussed and concluded that we need to inject datalayout when parsing the module.

Let's consider the situation where llc command line does not contain target.

The old code path just parses the LLVM assembly and gets the target from the assembly. It can do that because it does not need to inject the datalayout.

However, now we need to inject datalayout when parsing, then we cannot since we don't know datalayout unless we parse the module to know the target first.

My suggestion is

1. Introduce a function parseIRFileWithoutValidation, which does not drop invalid debug info and does not verify module.
2. Add an optional DataLayoutString argument to parseIRFile

parseIRFile will call parseIRFileWithoutValidation, then inject datalayout, then drop invalid debug info and verify the module.

only llc calls parseIRFileWithoutValidation, it will inject datalayout, drop invalid debuginfo and verify module by itself.

All other tools call parseIRFile. They either inject datalayout by command line option, or does not inject datalayout.

[aprantl]

I'm very sorry, I accidentally pasted a wrong review URL into a commit message!

[aprantl]

In D41832#989463, @yaxunl wrote:

In D41832#989406, @yaxunl wrote:

In D41832#989354, @aprantl wrote:

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

I'm probably missing something obvious here. The case where llc gets invoked without a target on the command line must be working today, doesn't it? Why can't we fall back to that code path?

This patch is trying to let llc load an llvm module which does not contain datalayout. In most cases, the parser is able to do that even though there is no datalayout in the module.

However, in some rare cases, the parser needs to know the datalayout to be able to parse the module. Therefore we discussed and concluded that we need to inject datalayout when parsing the module.

Let's consider the situation where llc command line does not contain target.

The old code path just parses the LLVM assembly and gets the target from the assembly. It can do that because it does not need to inject the datalayout.

However, now we need to inject datalayout when parsing, then we cannot since we don't know datalayout unless we parse the module to know the target first.

My suggestion is

1. Introduce a function parseIRFileWithoutValidation, which does not drop invalid debug info and does not verify module.

2. Add an optional DataLayoutString argument to parseIRFile

parseIRFile will call parseIRFileWithoutValidation, then inject datalayout, then drop invalid debug info and verify the module.

only llc calls parseIRFileWithoutValidation, it will inject datalayout, drop invalid debuginfo and verify module by itself.

All other tools call parseIRFile. They either inject datalayout by command line option, or does not inject datalayout.

That sounds good to me, thanks!

[aprantl]

Landed with Jim's changes as r323565.

[yaxunl]

Re-upload the patch.

[yaxunl]

Revised as discussed with Adrian.

It is even simpler than discussed since ParseIRFile etc. already have an argument to disable updating debug info. Therefore no new functions need to be added. Only need to add an argument for overriding data layout.

[aprantl]

Thanks, LGTM!

lib/CodeGen/MIRParser/MIRParser.cpp

240 ↗

(On Diff #131991)

Perhaps comment what false means?

[yaxunl]

lib/CodeGen/MIRParser/MIRParser.cpp

240 ↗

(On Diff #131991)

will add /*UpgradeDebugInfo=*/. This is used only by llc, so it is OK to do so since we upgrade debug info explicitly later.

www/trunk/OpenProjects.html

 <!--#include virtual="header.incl" -->
 
 <div class="www_sectiontitle">Open LLVM Projects</div>
 
 <ul>
   <li><a href="#gsoc18">Google Summer of Code 2018</a>
     <ul>
     <li>
+    <a href="http://lldb.llvm.org/"><b>LLDB</b></a><ul>
+      <li><a href="#lldb-reimplement-lldb-mi">Reimplement lldb-mi on top of the
+          LLDB public API</a>
+      </li>
+
+      <li><a href="#lldb-reimplement-lldb-cmdline">Reimplement LLDB's
+          command-line commands using the public SB API.</a>
+      </li>
+      <li><a href="#lldb-batch-testing">Add support for batch-testing to the LLDB
+          testsuite.</a>
+        </li>
+    </ul>
+    </li>
+    <li>
         <b>Others</b>
         <ul>
             <li><a href="#apt">Integrate libc++ and OpenMP in apt.llvm.org</a>
             </li>
         </ul>
    </li>
    </ul>
   </li>
<li><a href="#gsoc17">Google Summer of Code 2017</a>
     </ul>
     </li><li>
     <a href="http://compiler-rt.llvm.org/"><b>Compiler-rt</b></a><ul>
       <li><a href="#compiler-rt-port-to-other-platforms">Port compiler-rt
           components to other platforms</a>
       </li>
     </ul>
     </li><li>
-    <a href="http://lldb.llvm.org/"><b>LLDB</b></a><ul>
-      <li><a href="#lldb-reimplement-lldb-mi">Reimplement lldb-mi on top of the
-          LLDB public API</a>
-      </li>
-    </ul>
-    </li><li>
     <a href="http://lld.llvm.org/"><b>LLD</b></a><ul>
       <li><a href="#lld_layout">Improve Code Layout</a>
       </li>
     </ul>
     </li><li>
     <b><a href="http://polly.llvm.org">Polly</a></b><ul>
       <li>
   <a href="#pollypgo">Profile Guided Optimization in Polly</a></li>

 <p>The LLVM project has participated in Google Summer of Code for several years
 and has had some very successful projects. We hope that this year is no
 different and look forward to hearing your proposals. For information on how to
 submit a proposal, please visit the Google Summer of Code
 main <a href="https://developers.google.com/open-source/gsoc/">website.</a></p>
 
 
 <!-- *********************************************************************** -->
+<div class="www_subsection">
+  <a>LLDB</a>
+</div>
+<!-- *********************************************************************** -->
+
+<!-- *********************************************************************** -->
+<div class="www_subsubsection">
+  <a name="lldb-reimplement-lldb-cmdline">Reimplement LLDB's command-line commands
+  using the public SB API.</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="www_text">
+  <p><b>Description of the project: </b> Just as LLVM is a library to
+    build compilers, LLDB is a library to build debuggers. LLDB vends
+    a stable, public SB API. Due to historic reasons the LLDB command
+    line interface is currently implemented on top of LLDB's private
+    API and it duplicates a lot of functionality that is already
+    implemented in the public API. Rewriting LLDB's command line
+    interface on top of the public API would simplify the
+    implementation, eliminate duplicate code, and most importantly
+    reduce the testing surface.
+  </p>
+  <p>
+    This work will also provide an opportunity to clean up the SB API
+    of commands that have accrued too many overloads over time and
+    convert them to make use of option classes to both gather up all
+    the variants and also future-proof the APIs.
+  </p>
+  <p><b>Confirmed Mentor:</b>Adrian Prantl and Jim Ingham</p>
+
+  <p><b>Desirable skills:</b>
+    Intermediate knowledge of C++.
+  </p>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="www_subsubsection">
+  <a name="lldb-reimplement-lldb-mi">Reimplement lldb-mi on top of the LLDB
+    public SB API.</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="www_text">
+  <p><b>Description of the project: </b> <em>lldb-mi</em> implements a
+    machine-readable interface that is supported by many IDEs and text
+    editors. The current support is incomplete and does not implement
+    enough commands to work with most text editors. More importantly,
+    it isn't using the right abstraction layer: Instead of executing
+    textual commands via <em>handleCommand()</em> and scraping LLDB's
+    textual output, it should be using the methods and data structures
+    provided by the public SB API.
+  </p>
+  <p><b>Confirmed Mentor:</b> Adrian Prantl</p>
+
+  <p><b>Desirable skills:</b>
+    Intermediate knowledge of C++.
+  </p>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="www_subsubsection">
+  <a name="lldb-batch-testing">Add support for batch-testing to the LLDB
+    testsuite.</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="www_text">
+  <p><b>Description of the project: </b>One of the tensions in the
+    testsuite is that spinning up a process and getting it to some
+    point is not a cheap operation, so you'd like to do a bunch of
+    tests when you get there.  But the current testsuite bails at the
+    first failure, so you don't want to do many tests since the
+    failure of one fails all the others. On the other hand, there are
+    some individual test assertions where the failure of the assertion
+    <em>should</em> cause the whole test to fail.  For example, if you
+    fail to stop at a breakpoint where you want to check some variable
+    values, then the whole test should fail.  But if your test then
+    wants to check the value of five independent locals, it should be
+    able to do all five, and then report how many of the five variable
+    assertions failed. We could do this by adding <em>Start</em>
+    and <em>End</em> markers for a batch of tests, do all the tests in
+    the batch without failing the whole test, and then report the
+    error and fail the whole test if appropriate. There might also be
+    a nice way to do this in Python using scoped objects for the test
+    sections.
+  </p>
+  <p><b>Confirmed Mentor:</b> Jim Ingham</p>
+
+  <p><b>Desirable skills:</b>
+    Intermediate knowledge of Python.
+  </p>
+</div>
+
+
+<!-- *********************************************************************** -->
 <div class="www_sectiontitle">
   <a name="gsoc17">Google Summer of Code 2017</a>
 </div>
 <!-- *********************************************************************** -->
 
 <div class="www_text">
 
 <p>Google Summer of Code 2017 contributed a lot to the LLVM project. Below is a
<p><b>Description of the project: </b>
     to other platforms, for example, Mac OS, would be great!
   </p>
   <p><b>Confirmed Mentor:</b> Kuba Mracek, Anna Zaks</p>
 </div>
 
 
 <!-- *********************************************************************** -->
 <div class="www_subsection">
-  <a>LLDB</a>
-</div>
-<!-- *********************************************************************** -->
-
-<!-- *********************************************************************** -->
-<div class="www_subsubsection">
-  <a name="lldb-reimplement-lldb-mi">Reimplement lldb-mi on top of the LLDB
-    public API.</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="www_text">
-  <p><b>Description of the project: </b>
-    lldb-mi implements a machine-readable interface that is supported by many
-    IDEs. The current support is very incomplete and isn't using the right
-    abstraction layer. Instead of scraping LLDB's textual output, it should be
-    using the data structures provided by the public API.
-  </p>
-  <p><b>Confirmed Mentor:</b> Adrian Prantl, Greg Clayton</p>
-
-  <p><b>Desirable skills:</b>
-    Intermediate knowledge of C++.
-  </p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="www_subsection">
   <a>LLD</a>
 </div>
 <!-- *********************************************************************** -->
 
 <!-- *********************************************************************** -->
 <div class="www_subsubsection">
   <a name="lld_layout">Improve Code Layout</a>
 </div>