Displaying 20 results from an estimated 100 matches similar to: "Stack Usage is more in the libunwind library ."
2011 May 30
2
[LLVMdev] Crash in libunwind
Hello,
We have been investigating a crash in our application that may be related to how stack frames are generated by the JIT. We observe it with LLVM 2.9, but not with LLVM 2.8, everything else being the same. The crash occurs when dynamically generated code calls code that tries to unwind the stack.
Here is what the stack trace looks like on MacOSX 10.6 :
0 libSystem.B.dylib
2011 May 30
0
[LLVMdev] Crash in libunwind
This may be bogus, but do you have:
llvm::JITExceptionHandling = true;
for the code that generates the dynamic code?
It has been a while, but I don't recall what will happen when dynamic code, generated
with jit exception handling turned off, invokes libraries which in turn try to unwind the stack
via the libunwind api. However given that you say the code works with 2.8, my concern
2015 Jul 14
2
[LLVMdev] [llvm] [libunwind] r207467 misprint
Hi Nick!
In r207467 you added code(libunwind: DwarfInstructions.hpp):
assert(lastReg <= (int)cieInfo.returnAddressRegister
&& "register range does not contain return address
register");
for (int i = 0; i <= lastReg; ++i) {
.....
else if (i == (int)cieInfo.returnAddressRegister)
There is misprint here: lastReg should be >=
2020 Aug 15
5
Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
Hello.
I was trying to compile
https://github.com/llvm/llvm-project/tree/master/libunwind using:
- MSVC
- Clang
I wasn't able to configure this project for using MSVC (directly or via
clang-cl):
>cmake -G Ninja -DLLVM_PATH="C:/Users/clang/llvm-project-10.0.1/llvm"
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX="C:\Users\clang\libunwind_llvm" ../libunwind
--
2016 Dec 23
2
3.9 regression with legacy static assert macros (bad type resolution)
3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind:
#define COMPILE_TIME_ASSERT( expr ) \
extern int compile_time_assert_failed[ ( expr ) ? 1 : -1 ] __attribute__( ( unused ) );
I notice that the issue is fixed on current trunk. Does anyone know what revision introduced the fix? Can we get it
2016 Dec 27
2
3.9 regression with legacy static assert macros (bad type resolution)
It already shipped AFAIK: http://releases.llvm.org/download.html
—
Mehdi
> On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Can we still check patches into 3.9.1?
>
>> On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:
>>
>>
>>> On Dec 23, 2016, at 11:17,
2016 Dec 27
3
3.9 regression with legacy static assert macros (bad type resolution)
+Tom : is there a plan for a 3.9.2?
—
Mehdi
> On Dec 27, 2016, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> It already shipped AFAIK: http://releases.llvm.org/download.html
>
> —
> Mehdi
>
>> On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Can we still check patches into
2016 Dec 23
0
3.9 regression with legacy static assert macros (bad type resolution)
> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind:
>
> #define COMPILE_TIME_ASSERT( expr ) \
> extern int compile_time_assert_failed[ ( expr ) ? 1 : -1 ] __attribute__( (
2016 Dec 24
2
3.9 regression with legacy static assert macros (bad type resolution)
> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote:
>
>
>> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind:
>>
>> #define
2016 Dec 27
0
3.9 regression with legacy static assert macros (bad type resolution)
Can we still check patches into 3.9.1?
> On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:
>
>
>> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote:
>>
>>
>>> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>
2017 Jan 23
2
3.9 regression with legacy static assert macros (bad type resolution)
There's a regression in AMDGPU which would be nice to get resolved, see:
https://bugs.freedesktop.org/show_bug.cgi?id=99078
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.9/+bug/1656620?comments=all
I think it's reasonably low-risk to back-port
AMDGPU: Reduce the duration of whole-quad-mode
AMDGPU: Do not clobber SCC in SIWholeQuadMode
since they've been in trunk and
2005 Aug 16
0
CEBA-2005:xxx CentOS 3 ia64 - missing libunwind
Hi,
I've managed to left it out. I just realized it myself while installing
a test host for upcoming C3U6. I don't know how i managed to leave it
out, but i did and now it's fixed (no one has been complaining tho
which makes me wondering if there even is any CentOS-3/ia64
installations :)
files:
updates/ia64/RPMS/libunwind-0.97-4.ia64.rpm
--
Pasi Pirhonen - upi at iki.fi -
2015 Sep 27
2
[libunwind][Mips] Problem using gas to assemble UnwindRegistersSave.S
The latest TOT of libunwind fails for me when I build
UnwindRegistersSave.S for the Mips. My copy of clang uses a 2.25
binutils Mips assembler.
This is the message I get:
"/home/rich/ellcc/bin/mips-elf-as" -o
/tmp/UnwindRegistersSave-a2c974.o -EL /tmp/UnwindRegistersSave-545450.s
src/UnwindRegistersSave.S: Assembler messages:
src/UnwindRegistersSave.S:99: Error: opcode not
2015 Sep 27
2
[libunwind][Mips] Problem using gas to assemble UnwindRegistersSave.S
On 09/27/2015 06:41 PM, Vasileios Kalintiris wrote:
> Hi Richard,
>
> Clang doesn't have support for MIPS I. The trap-on-condition instructions were added in MIPS II and they should work fine. This is why it works with ".set mips32r2".
>
> Which version of the ISA did you specify when you used the integrated assembler?
>
> Thanks,
> Vasileios
>
>
Hi
2016 Nov 16
2
Clang 3.8 can't compile libunwind 3.9
Hi Logan,
So, I just realised clang 3.8 comes with an unwind.h which doesn't
have _URC_OK defined (introduced in r262178, just after 3.8 split).
But on that commit, the personality routine depends on it for EHABI
calls, which is defined by default on ARM environments.
The end result is that I can only use Clang 3.9+ to compile libunwind 3.9+.
2016 Feb 17
0
CEBA-2016:0203 CentOS 7 libunwind BugFix Update
CentOS Errata and Bugfix Advisory 2016:0203
Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-0203.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
6e1e40010c7725c9c2fe9e40cb6f560c02cd2d9832a779c817dc46d39375ca8b libunwind-1.1-5.el7_2.2.i686.rpm
2009 Oct 25
0
[LLVMdev] Producing a stack dump via libunwind?
Hi Talin,
> I'm using the LLVM exception handling intrinsics, along with a custom
> personality function, to do exception handling and it is working well.
> Now, I would like to add the ability to produce a human-readable stack
> backtrace for exceptions which are not caught (or rather, which are
> caught by some top-level function which prints the exception's stack
2016 Apr 16
2
[cfe-dev] [libunwind] __ELF__ macro for arm-none-eabi
On 16 April 2016 at 01:44, Zhao, Weiming via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> I'm building libunwind for ARM baremetal using clang.
> I notice that __ELF__ is used in libunwind and the macro is only defined for
> Linux target on ARM.
> Should we also predefine that for arm-none-eabi target?
Do you mean in Clang's ARMTargetInfo::getTargetDefines() ?
I think
2015 May 07
2
[LLVMdev] Recent libc++ failures due to libunwind
Hi,
During last 2-3 days I started to get some new regressions from the
libc++ testsuite, one of them is
std/containers/sequences/list/list.modifiers/insert_iter_iter_iter.pass.cpp
.
When run under gdb this seems to be a crash under libunwind code:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff73d00ce in
2016 Apr 18
2
[cfe-dev] [libunwind] __ELF__ macro for arm-none-eabi
On 18 April 2016 at 16:18, Silviu Baranga <Silviu.Baranga at arm.com> wrote:
> This doesn't look like something ACLE specific (I can't find it in the ACLE doc).
Sorry, I didn't mean it was ACLE, only that you guys were fiddling
with macros. :)
> This seems to be a generic macro. I think it would make sense to define it
> if we know we're emitting ELF.
Since the