similar to: [DbgInfo] Potential bug in location list address ranges

Displaying 20 results from an estimated 700 matches similar to: "[DbgInfo] Potential bug in location list address ranges"

2018 Apr 27
2
[DbgInfo] Potential bug in location list address ranges
As Adrian said, we'd need to see the source of foo() to assess what the location-list for bar ought to be. Without actually going to look, I would guess that 'poplt' is considered a conditional move, therefore r4's contents are not guaranteed after it executes (i.e. it is a clobber). If one operand of 'poplt' is 'pc' then of course it is also a conditional indirect
2018 Apr 27
0
[DbgInfo] Potential bug in location list address ranges
> On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi all, > > Consider this ARM assembly code of a C function: > > 00008124 <foo>: > 8124: push {r4, r6, r7, lr} > 8126: add r7, sp, #8 > 8128: mov r4, r0 > 812a: ldrsb.w
2018 May 07
2
[DbgInfo] Potential bug in location list address ranges
Hello, Has anyone taken a look at this bug? I really want to fix this, but as Paul pointed out, this requires a lot of care... Thank you for your help Son Tuan Vu On Fri, Apr 27, 2018 at 7:29 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > Thank you all for taking a look at this. I pasted the C source then > deleted it because I was afraid that it was too long to read...
2018 Apr 27
0
[DbgInfo] Potential bug in location list address ranges
Thank you all for taking a look at this. I pasted the C source then deleted it because I was afraid that it was too long to read... Here's the code of *foo*. Its real name is *verifyPIN*. The variable *bar* is *userPin*. int *verifyPIN*(char **userPin*, char *cardPin, int *cpt) { int i; int status; int diff; if (*cpt > 0) { status = 0x55; diff = 0x55; for (i = 0; i
2018 May 07
0
[DbgInfo] Potential bug in location list address ranges
Could you file a bug report about this (bugs.llvm.org <http://bugs.llvm.org/>)? If you don't have an account on bugzilla, I'd be happy to file one for you. Please provide exact instructions to reproduce the issue including any compilation flags. thanks, vedant > On May 7, 2018, at 9:16 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hello, > > Has
2017 Dec 06
2
[LLD] Slow callstacks in gdb
Rui Ueyama <ruiu at google.com> writes: > On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Martin Richtarsky <s at martinien.de> writes: >> >> > Output looks as follows [1] Seems sh_offset is missing? >> >> That is what readelf prints as Off >> >> > [17] .rela.text
2012 Jun 02
3
[LLVMdev] Big endian ARM?
Hi, I've been trying to set up clang/LLVM to compile for big endian ARM and I need a little help. The code generation works for the most part and most of my regression tests pass, but I noticed that code like this extern void g(void); int *p; int main() { if (*p & 0x01000000) g(); } generates ldr r0, [r0] ldrb r0, [r0, #3]
2020 Jul 20
2
[ARM] Should Use Load and Store with Register Offset
Hello LLVM Community (specifically anyone working with ARM Cortex-M), While trying to compile the Newlib C library I found that Clang10 was generating slightly larger binaries than the libc from the prebuilt gcc-arm-none-eabi toolchain. I looked at a few specific functions (memcpy, strcpy, etc.) and noticed that LLVM does not tend to generate load/store instructions with a register offset (e.g.
2020 Jul 21
2
[ARM] Should Use Load and Store with Register Offset
Hello Sjoerd, Thank you for your response! I was not aware that -Oz is a closer equivalent to GCC's -Os. I tried -Oz when compiling with clang and confirmed that the Clang's generated assembly is equivalent to GCC for the code snippet I posted above. clang --target=armv6m-none-eabi -Oz -fomit-frame-pointer memcpy_alt1: push {r4, lr} movs r3, #0 .LBB0_1: cmp
2012 Jun 03
0
[LLVMdev] Big endian ARM?
On Saturday, June 02, 2012 10:20:03 AM Richard Pennington wrote: > Hi, > > I've been trying to set up clang/LLVM to compile for big endian ARM and I > need a little help. The code generation works for the most part and most of > my regression tests pass, but I noticed that code like this > > extern void g(void); > int *p; > > int main() > { > if (*p
2014 Sep 11
2
[LLVMdev] Is shortening a load a bug?
When the IR specifies a 32 bit load can it be changed to a narrower load? What if the load is from memory (e.g. a peripheral) that only supports 32-bit access? Consider the following IR: ---- target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:32" target triple = "thumbv7m-unknown-unknown" @f = external global i32 define zeroext i8 @bar() nounwind { L.0:
2012 Jun 03
2
[LLVMdev] Big endian ARM?
On Jun 2, 2012, at 8:35 PM, Richard Pennington wrote: >> i.e. the test of the value is optimized to use a byte load, but the ldrb is >> done assuming a little endian address space. >> >> I've been snooping around, but can't seem to find where the conversion to a >> byte operation is done. Could someone point me in the right direction? >> > >
2011 Nov 16
0
[LLVMdev] LLVM 3.0 release notes ARM Target
what do you mean by "more optimal instructions" ? -omer On Wed, Nov 16, 2011 at 1:28 AM, Joe Abbey <jabbey at arxan.com> wrote: > I've done a first pass over the past 6 months of changes and some notable > things stood out: > > * The ARM backend has reworked Set Jump Long Jump EH Lowering. > * The ARM backend includes improved support for Cortex-M > *
2017 Dec 05
2
[LLD] Slow callstacks in gdb
Martin Richtarsky <s at martinien.de> writes: > Output looks as follows [1] Seems sh_offset is missing? That is what readelf prints as Off > [17] .rela.text RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible
2012 Jan 24
0
[LLVMdev] Use of 'ldrd' instructions with unaligned addresses on armv7 (Major bug in LLVM optimizer?)
On Tue, Jan 24, 2012 at 08:36:17AM -0800, Esperanza de Escobar wrote: > No one is arguing that there aren't ABI specs or LLVM design > guidelines that say that unaligned accesses "should not", "could not" > or "aren't guaranteed to" work, because it's besides the point. No, it is the core of the issue. Standard C gives the compiler certain
2011 Nov 16
4
[LLVMdev] LLVM 3.0 release notes ARM Target
I've done a first pass over the past 6 months of changes and some notable things stood out: * The ARM backend has reworked Set Jump Long Jump EH Lowering. * The ARM backend includes improved support for Cortex-M * The ARM backend adds parsing and encoding ARM/Thumb/Thumb2 assembly There are also many many code generation improvements which select more optimal instructions. Those seemed
2013 Sep 11
0
[LLVMdev] removing unnecessary ZEXT
Hi Andrew, Thank you for the suggestion. I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run. I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy). (See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.) Here is a
2015 May 28
1
[LLVMdev] [ARM backend] adding pattern for SMLALBB
Hi James/Tim, I am trying to add a patterns for SMLALBB I think these two assembly patterns can be reduced to SMLALBB using tablegen. 1) smulbb r2, r3, r2 adds r0, r2, r0 (RdLo) asr r3, r2, #31 adc r1, r3, r1 (RdHi) ==> smlalbb r0, r1, r3, r2 I have added pattern in def SMLALBB : AMulxyI64< ..... as below :- [] modified to ---> [((set GPR:$RdLo,
2012 Jan 24
4
[LLVMdev] Use of 'ldrd' instructions with unaligned addresses on armv7 (Major bug in LLVM optimizer?)
No one is arguing that there aren't ABI specs or LLVM design guidelines that say that unaligned accesses "should not", "could not" or "aren't guaranteed to" work, because it's besides the point. The point is that unaligned 32-bit loads and stores *work in practice* on every single ARM device Apple has ever manufactured. I'm not a hardware person, but
2010 Sep 14
1
[LLVMdev] global type legalization?
Returning to an old discussion here.... On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote: > On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >>> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function