Displaying 8 results from an estimated 8 matches for "addrorerr".
2017 Jul 27
2
llvm 5.0 release rc1 : ExecutionEngine fatal error on MCJIT::getFunctionAddress
...SymbolAddress(const std::string &Name, bool
CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream
MangledNameStream(MangledName);
Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); }
if (auto Sym = findSymbol(MangledName, CheckFunctionsOnly)) { if (auto
AddrOrErr = Sym.getAddress()) return *AddrOrErr; else {
report_fatal_error(AddrOrErr.takeError()); } } else {
report_fatal_error(Sym.takeError()); }}*
If the function findSymbol return nullptr, we are executing
report_fatal_error and kill everything :(
What is the reason for this change? Is thi...
2015 May 29
9
[LLVMdev] Error handling in LLVMObject library
...f they know the result
would be valid:
uint64_t Addr = getSymbolAddress(Symbol).get();
and it would fail the assert if they are wrong.
Cons:
* need to change lots of old code, or live with two versions of functions
* error handling boilerplate in regular code on call site is ugly:
auto AddrOrErr = getSymbolAddress(Symbol);
if (AddrOrErr.hasError())
return; // or continue, or whatever
uint64_t Addr = AddrOrErr.get();
(can probably be improved with a macro)
* adds extra overhead for cases when we're certain the result would be
valid.
On IRC discussion Lang suggested
3. Chec...
2015 May 30
1
[LLVMdev] Error handling in LLVMObject library
...lid:
> uint64_t Addr = getSymbolAddress(Symbol).get();
> and it would fail the assert if they are wrong.
>
> Cons:
> * need to change lots of old code, or live with two versions of functions
> * error handling boilerplate in regular code on call site is ugly:
> auto AddrOrErr = getSymbolAddress(Symbol);
> if (AddrOrErr.hasError())
> return; // or continue, or whatever
> uint64_t Addr = AddrOrErr.get();
> (can probably be improved with a macro)
> * adds extra overhead for cases when we're certain the result would be
> valid.
>
> O...
2015 Jun 01
2
[LLVMdev] Error handling in LLVMObject library
...lid:
> uint64_t Addr = getSymbolAddress(Symbol).get();
> and it would fail the assert if they are wrong.
>
> Cons:
> * need to change lots of old code, or live with two versions of functions
> * error handling boilerplate in regular code on call site is ugly:
> auto AddrOrErr = getSymbolAddress(Symbol);
> if (AddrOrErr.hasError())
> return; // or continue, or whatever
> uint64_t Addr = AddrOrErr.get();
> (can probably be improved with a macro)
> * adds extra overhead for cases when we're certain the result would be
> valid.
I think th...
2015 Jun 02
2
[LLVMdev] Error handling in LLVMObject library
...>>> and it would fail the assert if they are wrong.
>>>
>>> Cons:
>>> * need to change lots of old code, or live with two versions of
>>> functions
>>> * error handling boilerplate in regular code on call site is ugly:
>>> auto AddrOrErr = getSymbolAddress(Symbol);
>>> if (AddrOrErr.hasError())
>>> return; // or continue, or whatever
>>> uint64_t Addr = AddrOrErr.get();
>>> (can probably be improved with a macro)
>>> * adds extra overhead for cases when we're certain the...
2018 Mar 26
0
Interest in integrating a linux perf JITEventListener?
...::ST_Function)
> + continue;
> +
> + Expected<StringRef> Name = Sym.getName();
> + if (!Name) {
> + // TODO: Actually report errors helpfully.
> + consumeError(Name.takeError());
> + continue;
> + }
> +
> + Expected<uint64_t> AddrOrErr = Sym.getAddress();
> + if (!AddrOrErr) {
> + // TODO: Actually report errors helpfully.
> + consumeError(AddrOrErr.takeError());
> + continue;
> + }
> + uint64_t Addr = *AddrOrErr;
> + uint64_t Size = P.second;
> +
> + // According to spec d...
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