[PATCH} Remove '.bc' input support from the frontend

[David Blaikie]

On Thu, Jun 26, 2014 at 2:41 PM, Alp Toker <alp at nuanti.com> wrote:
>
> On 25/06/2014 09:17, Eric Christopher wrote:
>>>
>>> I'm not terribly invested in it - just mentioning that I/think/  I've
>>>
>>> >relied on this feature on at least a few occasions but it wouldn't be
>>> >hard for me to workaround - just one data point. Others may chime in
>>> >with clearer views.
>>> >
>>
>> I've definitely used the feature before and likely will again. That
>> said I personally don't mind doing llvm-dis on a bc file before doing
>> it.
>>
>> The main reason to keep some aspect of the functionality: It's the
>> only way to be sure you're actually passing a bit of bitcode through
>> the precise pipeline that clang has set up. :)
>>
>> -eric
>>
>
> So, I went ahead and wrote some tests to see if we can get some coverage.
>
> The source manager struggles to map errors to source locations in binary
> files, causing crashes:
>
> Assertion failed: (Line && Col && "Line and column should start from 1!"),
> function translateFileLineCol, file clang/lib/Basic/SourceManager.cpp, line
> 1597.
>
> Other times the backend segfaults:
>
> 4  libLLVMBitReader.dylib     0x000000010efe0816
> llvm::BitcodeReader::ParseBitcodeInto(llvm::Module*) + 62
> 5  libLLVMBitReader.dylib     0x000000010efe5b17
> llvm::getLazyBitcodeModule(llvm::MemoryBuffer*, llvm::LLVMContext&) + 129
> 6  libLLVMBitReader.dylib     0x000000010efe5cba
> llvm::parseBitcodeFile(llvm::MemoryBuffer*, llvm::LLVMContext&) + 44
> 7  libLLVMIRReader.dylib      0x000000010e09ad06
> llvm::ParseIR(llvm::MemoryBuffer*, llvm::SMDiagnostic&, llvm::LLVMContext&)
> + 190
> 8  libclangCodeGen.dylib      0x000000010df4412b
> clang::CodeGenAction::ExecuteAction() + 395
> 9  libclangFrontend.dylib     0x000000010d83f139
> clang::FrontendAction::Execute() +
>
> So it looks like some engineering will be involved if we want to support it
> as a first class feature.
>
> I'll try to find a spare day or two to work on this if people really want
> the feature I guess!

Depending on how much time it takes you, I suspect it might not be
worthwhile making it a "first class" feature. Just a handy utility for
developers from time to time - if llc/opt/llvm-dis suffices, we can
probably do without.

Depends what your priorities/interests - doubt anyone will complain if
it gets better, certainly.

What error cases did you hit that caused the above stack trace? just
out of curiosity.

- David