similar to: [Sanitizers] Platforms that don't support stack unwinding

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

2018-01-24 0:23 GMT+08:00 Ben Craig <ben.craig at ni.com>: > The high level of what happens is that __builtin_eh_return forces a spill > of all the non-volatile registers. The unwinder then has a starting point > for populating and adjusting those non-volatile registers. > > > > This approach usually requires that the function calling > __builtin_eh_return be built

Cool this is better than I expected - I never thought about the YAML support. And the document reference is really very good. Thanks Francis, MartinO -----Original Message----- From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com] Sent: 05 February 2018 21:43 To: Martin J. O'Riordan <MartinO at theheart.ie> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; Adam Nemet

On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/19/2018 7:21 PM, 陳韋任 wrote: >> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? > > Our exception handling runtime uses __builtin_eh_return. Does this mean that you know what it

I have this test case in my frontend, which is triggering an assert in llvm master branch: fn fnWithAlignedStack() -> i32 { @setAlignStack(1024); return 1234; } It sets alignstack=1024 in the function attributes (see http://llvm.org/docs/LangRef.html#function-attributes). It's tripping an assert: llvm/lib/IR/Attributes.cpp:134: static llvm::Attribute

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

I recently debugged an issue where I wasn't getting stack traces from ASAN on 32-bit ARM (on Android) when using a libclang_rt.asan-arm-android.so I'd built myself. I finally ended up tracing it to a build issue; the CMake build check for -funwind-tables was failing (because of some missing link libraries), so compiler-rt wasn't being built with that flag, which in turn led to all

Hello, I have been working on porting ASan to AArch64. I am building compiler-rt in "standalone mode" targeting aarch64. My build is successful, but I get the following runtime error when I run an ASan enabled executable through qemu-aarch64: ==29184==Parsed ASAN_OPTIONS: verbosity=1 ==29184==AddressSanitizer: failed to intercept '__isoc99_printf' ==29184==AddressSanitizer:

The high level of what happens is that __builtin_eh_return forces a spill of all the non-volatile registers. The unwinder then has a starting point for populating and adjusting those non-volatile registers. This approach usually requires that the function calling __builtin_eh_return be built without optimizations, because the optimizer will then remove the spills. From: llvm-dev

Hi David, Thank you very much for your response. I also get correct results for my example (for a 64-bit target) if the upper bounds are changed to unsigned. The reason is simply because clang zero-extends `m` for address calculations but sign-extends it for the loop upper bound. This prevents SCEV from canceling out the 'm' term from the difference expression that looks like `(-3 +

"git remote get-url" is apparently fairly new, the old version is "git config remote.origin.url". Might be worth using that for compatibility. On Mon, Jul 29, 2019, 5:11 PM Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > Hey Cam, it works for me on TOT (89fb9e8ce15). > > What does the failed command return for you? It should be: > > > git

Thanks Krzysztof. That's very helpful - I was missing the distinction between a register containing an undefined value and a register marked as containing an undefined value. Cheers! On 1/23/18, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Send llvm-dev mailing list submissions to > llvm-dev at lists.llvm.org > > To subscribe or unsubscribe via the World Wide Web,

Hello Under the proviso that it's been a while since I looked into any of these things... On 05/15, Bardia Mahjour via llvm-dev wrote: > I also get correct results for my example (for a 64-bit target) if the upper > bounds are changed to unsigned. The reason is simply because clang zero-extends > `m` for address calculations but sign-extends it for the loop upper bound. This >

Hi all, I have been looking at the `DependenceAnalysis` pass in `llvm/include/llvm/Analysis/DependenceAnalysis.h`. In order for this analysis to produce accurate dependence vectors for multi-dimensional arrays in nested loops, it needs to "delinearize" array element accesses to recover the subscripts in each dimension of the array. I believe that the current implementation of

Hi Ivan, The code that we have is indeed different from what the 'standard llvm' expects. Let me explain: in our version we came into this situation in two steps: 1) I added support for 'special types' that map directly to types supported by hardware. These types are represented by a struct containing a single iXXX member, providing the necessary bits of the type, and at the

Hello Yes, I agree that the SCEV cannot be simplified. Is my understanding correct that it is passed to a function like "isKnownNegative"? Which could still be able to prove is always true. The delinearisation may be valid, depending on exactly how you define delinearisation (under what conditions it should be giving results). It would be invalid for DA to return a dependency of [0