Displaying 4 results from an estimated 4 matches for "consumeerror".
2020 Apr 13
2
LLVM 10 ORC2 issue with symbol resolution
Hi Dibyendu,
I had a look - to be honest I am not sure where the error is being
> reported from. It looks like this:
> JIT session error: Symbols not found: [ luaV_tointeger_, luaG_runerror ]
> I don't think it is from any logging I am doing.
Errors in ORC may trigger cascading failures. E.g. if two different modules
M1 and M2 both reference a function "foo" which cannot
2018 Mar 26
0
Interest in integrating a linux perf JITEventListener?
...ymbolRef Sym = P.first;
> + std::vector<LLVMPerfJitDebugEntry> LineInfo;
> + std::string SourceFileName;
> +
> + Expected<SymbolRef::Type> SymTypeOrErr = Sym.getType();
> + if (!SymTypeOrErr) {
> + // TODO: Actually report errors helpfully.
> + consumeError(SymTypeOrErr.takeError());
> + continue;
> + }
> + SymbolRef::Type SymType = *SymTypeOrErr;
> + if (SymType != SymbolRef::ST_Function)
> + continue;
> +
> + Expected<StringRef> Name = Sym.getName();
> + if (!Name) {
> + // TODO: Actuall...
2016 Dec 29
1
Interest in integrating a linux perf JITEventListener?
Having something like this available in tree would definitely be
useful. For simplicity, why don't we start with support for the second
style? This is the long term useful one and would be a good starting
point for getting the code in tree. Can you give a pointer to the patch
so that I can assess the rough complexity? If it's simple enough, I'd
be happy to help get it reviewed
2017 Feb 02
0
Interest in integrating a linux perf JITEventListener?
Hi,
On 2016-12-29 13:17:50 -0800, Philip Reames wrote:
> Having something like this available in tree would definitely be
> useful.
Cool.
> For simplicity, why don't we start with support for the second style? This
> is the long term useful one and would be a good starting point for getting
> the code in tree.
Works for me.
> Can you give a pointer to the patch so that