search for: vlas

I'm not someone who thinks VLAs are automatically bad and unlike Linux kernel code they can sometimes be used safely in userspace. However for an internet exposed server there is an argument that they might cause some kind of exploitable situation especially if the code is compiled without other stack hardening features. Also i...

On 9/5/19 6:28 AM, Richard W.M. Jones wrote: > I'm not someone who thinks VLAs are automatically bad and unlike Linux > kernel code they can sometimes be used safely in userspace. However > for an internet exposed server there is an argument that they might > cause some kind of exploitable situation especially if the code is > compiled without other stack hardeni...

Since we don't know much about the calling environment, which might have a limited stack, might be taking input from untrusted sources, or we might not have other stack protections enabled, it's best to be cautious about using unbounded stack allocations. We're not in fact using them in libnbd, but this change prevents them from being added in future. --- configure.ac | 2 +- 1 file

...an affine > function *with constant multipliers*, eg: 3*x + 10*y. I merely argue for allowing constant-but-unknown multipliers, i.e., parameters. They're still affine for purposes of dependence analysis (by things like the Delta test or Polly), but oh so much more useful. Multi-dimensional VLAs happen, especially in scientific code. How are we going to express DGEMM (matrix multiplication)? We could do it by manually linearizing all the array references, or we could do it the way god intended when he standardized C90, with VLAs. I'm arguing that it would be wonderful to be able to an...

...h constant multipliers*, eg: 3*x + 10*y. > > I merely argue for allowing constant-but-unknown multipliers, i.e., > parameters. They're still affine for purposes of dependence analysis > (by things like the Delta test or Polly), but oh so much more useful. > > Multi-dimensional VLAs happen, especially in scientific code. How are > we going to express DGEMM (matrix multiplication)? We could do it by > manually linearizing all the array references, or we could do it the > way god intended when he standardized C90, with VLAs. I'm arguing that > it would be wonder...

First-- thanks to Daniel Dunbar for reporting this issue from my earlier coarse report on IRC and to Devang Patel for fixing it. I'm writing to request that this fix (r81058) find its way into the 2.6 release. Code compiled with clang that uses VLAs is horribly broken without r81058 (at least on x86-64). I don't know if it has any other implications but it's definitely greatly stabilizing for our code base. Thanks, Mike PS -- I am not subscribed to this list. -- Michael P. Lyle Chief Executive Officer Translattice, Inc. mly...

...r instance) or give up on it and abort. That also means that you cannot >> compile code that depends on knowing pointer sizes in the preprocessor, etc. >> >> >> Ok, that makes sense. It could be done by generalizing the notions of >> variably modified types (which are VLAs in C99) to include pointers. >> > I have read the sizeof and VLA in C99 I found a example: EXAMPLE 3 In this example, the size of a variable-length array is computed and returned from a function: #include <stddef.h> size_t fsize3(int n) { char b[n+3]; // variable length array ret...

...sal we could > transform preallocated->byval, but that isn’t very exciting. > I suppose we could say that the combo of byval+preallocated just means `byval`, and teach transforms that that's OK. > How does this interact with other dynamic stack allocations? Should we > switch VLAs to use a similar mechanism? (The problems with dynamic alloca > in general aren’t as terrible, but it might still benefit: for example, > it’s much easier to transform a dynamic allocation into a static > allocation.) > VLAs could use something like this, but they are generally of unk...

...asn't previous mattered as LLVM produces valid instruction sequences for variable adjustments anyway using an intermediate register. However, we have a recent requirement to also perform custom handling of stack adjustments for non-immediate values, for instance those that reserve stack for VLAs and 'alloca'. I would like to be able to intercept lowering for these where a computed value is used, and to be able to differentiate between when stack is being reserved and when it is being released. Where should I best handle this? All of the targets that use the 'ADJCALLSTACK&...

...they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Gustavo A. R. Silva <gustavo at embeddedor.com> --- Changes in v2: - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change is based on the feedback provided by David Laight. Thanks David. drivers/gpu/drm/no...

...hich can be both a runtime bug >> or a security flaw. Also, in general, as code evolves it is easy to >> lose track of how big a VLA can get. Thus, we can end up having runtime >> failures that are hard to debug. >> >> Also, fixed as part of the directive to remove all VLAs from >> the kernel: https://lkml.org/lkml/2018/3/7/621 >> >> Signed-off-by: Gustavo A. R. Silva <gustavo at embeddedor.com> >> --- >> Changes in v2: >> - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change >> is based on the feedbac...

On Fri, Mar 19, 2010 at 3:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 19, 2010, at 11:08 AM, 琬菁楊 wrote: > > > Hello Tristan and all, > > I have already know that if I want to do this feature(c -> EFI Byte code) > for GCC > I should further modify the GCC front end(parser) to solve the problem (the > size > of pointer is determined at

...gt;> or a security flaw. Also, in general, as code evolves it is easy to >>>> lose track of how big a VLA can get. Thus, we can end up having runtime >>>> failures that are hard to debug. >>>> >>>> Also, fixed as part of the directive to remove all VLAs from >>>> the kernel: https://lkml.org/lkml/2018/3/7/621 >>>> >>>> Signed-off-by: Gustavo A. R. Silva <gustavo at embeddedor.com> >>>> --- >>>> Changes in v2: >>>> - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE....

...2:27 PM, Michael Lyle wrote: First-- thanks to Daniel Dunbar for reporting this issue from my > earlier coarse report on IRC and to Devang Patel for fixing it. > > I'm writing to request that this fix (r81058) find its way into the > 2.6 release. Code compiled with clang that uses VLAs is horribly > broken without r81058 (at least on x86-64). I don't know if it has > any other implications but it's definitely greatly stabilizing for our > code base. Makes sense. Tanya, please pull http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086443.html...

Hi, is there a convenient way to get all allocations popped from the stack by llvm.stackrestore? Is this even decidable at compile time? Thanks Marc

...{ > size_t size; > size = fsize3(10); // fsize3 returns 13 > return 0; > } > And I found some information with clang about VLA > (http://clang.llvm.org/cxx_compatibility.html#vla) > Does llvm/clang doesn't support sizeof is evaluated at run time?? Yes, clang supports vlas as defined in C99 and sizeof can return a dynamic value. C99 vlas cannot occur in structs though, and clang does not support them in structs. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100401/e...

...t previous mattered as LLVM produces valid instruction sequences for variable adjustments anyway using an intermediate register. > > However, we have a recent requirement to also perform custom handling of stack adjustments for non-immediate values, for instance those that reserve stack for VLAs and ‘alloca’. I would like to be able to intercept lowering for these where a computed value is used, and to be able to differentiate between when stack is being reserved and when it is being released. > > Where should I best handle this? All of the targets that use the ‘ADJCALLSTACK’ nod...

Hi all, the language reference for the alloca instruction states: The ‘alloca‘ instruction allocates memory on the stack frame of the currently executing function, to be automatically released when this function returns to its caller. when using come c code like void myfunc(void){ int i=4; double d[i]; } the ir shows enclosing llvm.stackSave & restore constructs, enclosing the alloca

...goal of the redesign. > Connecting nested llvm.call.setups using tokens might make it easier for > passes to reason about the nesting, since the region nest would be > explicitly encoded. > I agree, that could be useful, it would replicate what we did for exception handling. > > VLAs could use something like this, but they are generally of unknown > size while call sites have a known fixed size. I think that makes them > pretty different. > > I don’t think we need to implement it at the same time, but the systems > would interact, so it might be worth planning ou...

Thanks all. David why do you say it is particularly bad IR (other than not having gone through SROA). Is it the multiple blocks for early returns? That is how I'm supporting early returns in the middle of a basic block. I couldn't find any other way. On Sun, Apr 5, 2015 at 6:24 AM, David Jones <djones at xtreme-eda.com> wrote: > Data point: > > I use (rarely) alloca in