Displaying 17 results from an estimated 17 matches similar to: "Windows "0xC00001A5: An invalid exception handler routine has been detected" with LLVM win32 (i386) SEH code"
2018 Aug 20
2
Windows "0xC00001A5: An invalid exception handler routine has been detected" with LLVM win32 (i386) SEH code
Indeed, it's 32bits x86 and there's no .safeseh or anything like it,
even readobj -coff-load-config says nothing:
File: ConsoleApplication830.exe
Format: COFF-i386
Arch: i386
AddressSize: 32bit
Now I know what to look for, thanks!
On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote:
> This is 32-bit x86, right? Sounds like the exception handler did not
> appear in the /safeseh
2016 Dec 21
2
debug info "ref" parameter
I want to emit a ref parameter (ie i32*) as if it was i32 in debug info,
however when I emit it with llvm.debug.declare referring to the
parameter register it shows the actual pointer value of the debug
register, instead of the value it refers to. This works fine if the
llvm.debug.declare points to a local alloca, how can this be and how can
I make it work so both show the integer value
2016 Dec 21
0
debug info "ref" parameter
Could you provide the complete example (with all the necessary metadata to
reproduce)?
Possible LLVM has a special case for arguments, I'm not sure/don't recall
off hand, but can poke around at it & see if there's a reasonable logic to
it.
On Tue, Dec 20, 2016 at 10:43 PM Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I want to emit a ref parameter (ie
2016 Dec 21
2
debug info "ref" parameter
https://gist.github.com/carlokok/77010598f81e8167592e593ec6c715a1
If needed I can strip it down more tomorrow, but only elements entry point and the two meh methods are used.
On December 21, 2016 8:27:12 PM GMT+01:00, David Blaikie <dblaikie at gmail.com> wrote:
>Could you provide the complete example (with all the necessary metadata
>to
>reproduce)?
>
>Possible LLVM has a
2017 Oct 29
2
A query language for LLVM IR (XPath)
Hi, sometimes when dealing with LLVM IR getting to a desired point of
the code is a bit cumbersome, in particular if you're instrumenting
existing code. A lot of nested loops and if checks.
Maybe all of this could be avoided by employing a query language. Since
an LLVM module can be seen as a sort of tree with attributes, I think
that reusing an existing query language for XML would be
2017 Oct 31
2
A query language for LLVM IR (XPath)
As much as I'm not a fan of most XML things, this application of XPath is *inspired*.
This would be a great testing/query tool for tests.
It would also be a great way to prototype passes.
Looking forward to seeing something like this in llvm/tools/ !
Cheers
> On 1 Nov 2017, at 04:00, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> This is so cool! I once
2020 Nov 18
1
invalid symbol kind for ADRP relocation
hi,
does anyone know how to resolve this? It's a very simple IR file (below), fails with:
LLVM ERROR: invalid symbol kind for ADRP relocation
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: \p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe -O0 debug_output(1).ll -filetype=obj
#0 0x01522349
2012 Nov 10
2
[LLVMdev] Saving a reference to a Basic Block?
Is there a way to save a reference to a Basic Block that gets all fixed up
in the linker, so that you can branch to it during execution? (Or maybe
just a better way to do what I'm trying to do?)
In my old-school BASIC compiler that I'm writing with LLVM, for each GOSUB,
I keep a map of an integer ID and a pointer to the basic block following
the GOSUB to return to.
Then, when a BASIC
2016 Dec 22
0
debug info "ref" parameter
if you could simplify it down a bit, that might be helpful - not sure
there's a lot to be gained - I imagine it is just a quirk of how we handle
these things in the backend to make normal debug info work, but there might
be some things to be done to help.
On Wed, Dec 21, 2016 at 2:31 PM Carlo Kok <ck at remobjects.com> wrote:
>
2018 Mar 14
3
lld/lto/win32 crash on DIE code
I have a fairly recent LLD/LTO llvm crashing on
DIE *ContextDIE = getOrCreateContextDIE(Context)
being null for a (local) variable. (Context is a DICompileUnit in this
case, but it's not present in MDNodeToDieMap so it returns null.
callstack is:
llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode)
Line 718 C++
llvm::DwarfUnit::addType(llvm::DIE & Entity, const
2018 Mar 30
0
[LLD] Mixing bitcode and native code
The problem is a bitcode implementation that has a stdcall function that's used from native code. 1 side has _elements_exception_handler, compiled that would be __elements_exception_handler at 20 due to stdcall. The native bit has the mangled name and the linker can't find it as the bitcode indexes have it without mangling.
I'll try to prepare a testcase when I get back in the office.
2018 Mar 16
0
lld/lto/win32 crash on DIE code
Hello Carlo,
I tried your reproducer and faced different problem from one you described
(I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens
when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function:
ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext
This happens because LLVM
2018 Mar 30
2
[LLD] Mixing bitcode and native code
Mixing native and bitcode files should just work, and that happens all the
time, as most programs need at least crt.o (which is a precompiled native
object file containing startup code).
Could you elaborate the issue a bit? It might be a bug in lld.
On Fri, Mar 30, 2018 at 3:11 AM Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Fri, Mar 30, 2018, at 11:23, Carlo Kok
2018 Mar 30
1
[LLD] Mixing bitcode and native code
Clang may be avoiding this problem because it will always emit
"\01__elements_exception_handler at 20" as the function name. It probably does
that for precisely this reason.
On Fri, Mar 30, 2018 at 11:55 AM Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The problem is a bitcode implementation that has a stdcall function that's
> used from native code. 1
2018 Mar 20
2
lld/lto/win32 crash on DIE code
Op 16-3-2018 om 20:16 schreef Evgeny Leviant:
> Hello Carlo,
>
> I tried your reproducer and faced different problem from one you described
> (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens
> when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function:
>
>
2018 Apr 03
0
[LLD] Mixing bitcode and native code
Seems my problem was the reverse; the definition did NOT have stdcall properly set; which is why i wasn't found. Setting that and everything worked. Thanks for the help.
On Fri, Mar 30, 2018, at 23:40, Reid Kleckner wrote:
> Clang may be avoiding this problem because it will always emit "\01__elements_exception_handler at 20" as the function name. It probably does that for
2018 Mar 20
0
lld/lto/win32 crash on DIE code
This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction
in @_island_debug_invoke and many other functions. The code expects either pointer to a filter
function or null in first operand, while you're passing pointer to structure:
catchpad within %80 [{i8*, i8*}* anon..., ...]
________________________________________
От: Carlo Kok <ck at