Opt crashes if not given stdin input

[gbMattN]

Running opt in a mode where it accepts its input via stdin, and then not providing any input results in a crash. An example of when this could happen is by piping in the IR generated with an optimization pass, however said pass errors out.
This is a regression starting from llvm11. llvm10 fails gracefully in this case. This crash was found while using Ubuntu 22.04, and has been reproduced using llvm17.0.1.

llvm11:

$ build/bin/opt -S llvm/test/Transforms/SampleProfile/section-accurate-samplepgo.ll -passes=sample-profile -sample-profile-file=nonexistant.prof | build/bin/opt -S -codegenprepare
error: nonexistant.prof: Could not open profile: No such file or directory
LLVM ERROR: Trying to construct TargetPassConfig without a target machine. Scheduling a CodeGen pass without a target triple set?
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: build/bin/opt -S -codegenprepare
 #0 0x00005555590214e4 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/gbmatt/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:22
 #1 0x000055555902187c PrintStackTraceSignalHandler(void*) /home/gbmatt/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:1
 #2 0x000055555901f2a3 llvm::sys::RunSignalHandlers() /home/gbmatt/llvm-project/llvm/lib/Support/Signals.cpp:68:20
 #3 0x0000555559020e26 SignalHandler(int) /home/gbmatt/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1
 #4 0x00007ffff7fae420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #5 0x00007ffff7a4b00b raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #6 0x00007ffff7a2a859 abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:81:7
 #7 0x0000555558f18c0e llvm::install_bad_alloc_error_handler(void (*)(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, bool), void*) /home/gbmatt/llvm-project/llvm/lib/Support/ErrorHandling.cpp:130:61
 #8 0x0000555558f189bb llvm::report_fatal_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, bool) /home/gbmatt/llvm-project/llvm/lib/Support/ErrorHandling.cpp:86:77
 #9 0x000055555822783b /home/gbmatt/llvm-project/llvm/lib/CodeGen/TargetPassConfig.cpp:460:21
#10 0x000055555822d07b llvm::Pass* llvm::callDefaultCtor<llvm::TargetPassConfig>() /home/gbmatt/llvm-project/llvm/include/llvm/PassSupport.h:80:76
#11 0x00005555585363ee llvm::PassInfo::createPass() const /home/gbmatt/llvm-project/llvm/include/llvm/PassInfo.h:102:3
#12 0x000055555852e674 llvm::PMTopLevelManager::schedulePass(llvm::Pass*) /home/gbmatt/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:789:38
#13 0x0000555558536f12 llvm::legacy::PassManagerImpl::add(llvm::Pass*) /home/gbmatt/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:560:3
#14 0x0000555558532fdb llvm::legacy::PassManager::add(llvm::Pass*) /home/gbmatt/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1732:1
#15 0x0000555556147191 OptCustomPassManager::add(llvm::Pass*) /home/gbmatt/llvm-project/llvm/tools/opt/opt.cpp:340:17
#16 0x000055555613efa4 addPass(llvm::legacy::PassManagerBase&, llvm::Pass*) /home/gbmatt/llvm-project/llvm/tools/opt/opt.cpp:375:17
#17 0x0000555556141a22 main /home/gbmatt/llvm-project/llvm/tools/opt/opt.cpp:893:22
#18 0x00007ffff7a2c083 __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:342:3
#19 0x000055555610d8ee _start (build/bin/opt+0xbb98ee)
Aborted (core dumped)

llvm10:

$ build/bin/opt -S llvm/test/Transforms/SampleProfile/section-accurate-samplepgo.ll -passes=sample-profile -sample-profile-file=nonexistant.prof | build/bin/opt -S -codegenprepare
error: nonexistant.prof: Could not open profile: No such file or directory
; ModuleID = '<stdin>'
source_filename = "<stdin>"

[gbMattN]

Some notes on what I have discovered so far:
In llvm10.0.0, PMTopLevelManger schedules 3 passes, Profile summary info, Natural Loop information and Dominator Tree Construction.
In llvm 11.0.1, After Profile summary info, it tries Target Pass Configuration. Which results in the crash. If you hardcode a check to skip that pass, it progresses to add the next 2 llvm10.0.0 did too. However, it later tries to add a Target Pass Configuration again, despite not having a target requested. This means it tries calling the default constructor, and crashes.
I don't have enough familiarity with the code to know where is best practice to put a check for this, nor really where it is getting these passes from, but I will keep investigating and see what falls out.

[gbMattN]

Checking if the buffer from stdin has size 0 fixes this, but a stack dump is also caused by
echo | build/bin/opt -S -codegenprepare
the difference being that the buffer in getMemoryBufferForStream has size 1 rather than 0, making the check lightly more difficult.