[llvm-dev] Reporting source errors from MCCodeEmitter::encodeInstruction() ? (original) (raw)

Thomas Goodfellow via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 6 01:19:18 PST 2020

Having re-read your first mail with better attention, you're quite correct: MCContext::reportError() does give a good error pathway from llvm-mc (no .o emitted, exit code == 1), and that's the answer to my problem, i.e. something like:

if(warning) { auto SM(CTX.getSourceManager()); if(SM) { SM->PrintMessage(MI.getLoc(), SourceMgr::DK_Warning, msg); return; } // without SrcMgr least-worst approach is promoting warning to error } CTX.reportError(MI.getLoc(), msg);

Having a similar MCContext::reportWarning() API to conceal the SrcMgr plumbing would be nice.

Thanks again for your help!

On Thu, 6 Feb 2020 at 00:23, Reid Kleckner <rnk at google.com> wrote:

Well, MCContext::reportError does track errors, so llvm-mc could check for errors at the end. On Wed, Feb 5, 2020 at 3:59 AM Thomas Goodfellow <thomas.goodfellow at gmail.com> wrote:

Thanks - having looked further it doesn't seem SourceManager does anything around PrintMessage() beyond emitting nice contextual error messages. Here's an invocation from AsmParser::printError(): HadError = true; printMessage(L, SourceMgr::DKError, Msg, Range); printMacroInstantiations(); return true; So seemingly the error tracking is down to the invoker, although it might be nice if counting errors and warnings was part of the SourceManager functionality. Somewhat surprisingly it seems that frontends such as Clang don't use this mechanism at all? (weak evidence for this assertion being that clang only uses setDiagHandler() for the case of inline assembly, and a breakpoint on PrintMessage() isn't hit for C/C++ parse errors) That leaves the question of how errors are most politely handled from the level of MCCodeEmitter::encode/emitInstruction, i.e. ideally allowing evaluation to proceed for subsequent instructions so that all errors get presented at once but then handling it as an overall failure. On Wed, 5 Feb 2020 at 00:36, Reid Kleckner <rnk at google.com> wrote: > > I was going to say use MCContext::reportError, but that mainly calls SourceManager::PrintMessage. Does that not prevent clang from emitting a .o file? That seems like a bug if so. > > On Tue, Feb 4, 2020 at 2:59 PM Thomas Goodfellow via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> [apologies for this duplicate post: originally sent to lldb-dev by not >> paying attention to the address auto-completion] >> >> We have a backend for a target that at present only detects some >> assembler errors when emitting instructions (basically because the >> platform has configurable properties with dependencies between >> instructions and it was easier to check for their interaction late >> than try to detect them earlier, e.g. through custom encoder methods >> and tablegen). Emitting diagnostics through >> SourceManager::PrintMessage() "works" in the limited sense of >> communicating the problem to a human, however it doesn't prevent >> generation of an incorrect output file or change the process exit >> code. >> >> We'd prefer not to resort to reportfatalerror() since that isn't a >> polite way to diagnose problems in the source. >> >> Is there a sensible way to properly signal a source error from the >> level of encodeInstruction()? Or is it expected that all such errors >> are reported earlier? _>> ________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list