search for: localvars

Here is my thought process on why the application crashes with a protection violation reading a section of memory. I used IDA to disassemble the app. Here's the section where it reads from memory and crashes because of a protection violation: 00760D4A sub_760D4A proc near ; CODE XREF: sub_75FCB0+159^Xp 00760D4A push ebp 00760D4B mov

Hi all, I'm using clang + LLVM 2.9. Let's consider following code sample: extern void bar(int x) ; void foo(int y) { bar(y) ; } When compiled with clang at -O2 -g I've got following LLVM file: ; ModuleID = 'localvar.c' target datalayout =

...eval NSUBSHELL [klibc] [INPUT] Use exit status 127 when the script to run does not exist Harald van Dijk (2): [klibc] [EVAL] Let funcnode refer to a function definition, not its first command [klibc] [SHELL] Improve LINENO support Herbert Xu (22): [klibc] [VAR] Add localvars nesting [klibc] [VAR] Fix poplocalvar leak [klibc] [VAR] Move unsetvar functionality into setvareq [klibc] [VAR] Replace cmdenviron with localvars [klibc] [VAR] Fix poplocalvar on abnormal exit from function [klibc] [VAR] Do not poplocalvars prematurely on regular util...

Hi, I have a question regarding the LLParser and the new type system rewrite when running the JIT. I think there may be a problem with the parser not picking up on named types currently defined in a given Module (global context). However, I don't have much experience with the LLVM internals so there's a good chance that I'm not fully understanding the new changes ;) For Example:

...itDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: eval: Always set localvar_stop [ dash commit 42298df5898a62f0df893be3af029d7e981623bd ] The variable localvar_stop is set iff vlocal is true. gcc doesn't get this so we get a spurious warning. This patch fixes this by always calling pushlocalvars with vlocal and making it only actually do the push if vlocal is non-zero. Signed-off-by: Herbert Xu <herbert at gondor.apana.org.au> Signed-off-by: Ben Hutchings <ben at decadent.org.uk> --- usr/dash/eval.c | 9 +++------ usr/dash/var.c | 12 +++++++++--- usr/dash/var.h | 2 +-...

...lags; + int vlocal; errlinno = lineno = cmd->ncmd.linno; if (funcline) @@ -745,7 +747,6 @@ evalcommand(union node *cmd, int flags) /* First expand the arguments. */ TRACE(("evalcommand(0x%lx, %d) called\n", (long)cmd, flags)); setstackmark(&smark); - localvar_stop = pushlocalvars(); file_stop = parsefile; back_exitstatus = 0; @@ -759,6 +760,8 @@ evalcommand(union node *cmd, int flags) cmd_flag = 0; execcmd = 0; spclbltin = -1; + vflags = 0; + vlocal = 0; path = NULL; argc = 0; @@ -770,6 +773,8 @@ evalcommand(union node *cmd, int flags) find_command(arg...

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

On Mon, Feb 2, 2015 at 9:51 AM, Robin Eklind <carl.eklind at myport.ac.uk> wrote: > (forgot to cc the list) > > Answers, questions and assumptions are inlined in the response. > > If someone with knowledge of the LLVM IR type system could take a look at > my assumptions below I'd be very happy. > > On 01/30/2015 02:24 AM, Sean Silva wrote: > >> On Thu,

Hello Sean, Thank you for your reply. I'll give your suggestion to item 6 and 7 a try tonight. I'll start a compilation and let it run throughout the night. My laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time :) Regarding item 8. I don't know if anyone is using "": in the wild so fixing the implementation might make sense. If not the

On Wed, Jan 28, 2015 at 6:28 PM, Robin Eklind <carl.eklind at myport.ac.uk> wrote: > Hello Sean, > > Thank you for your reply. I'll give your suggestion to item 6 and 7 a try > tonight. I'll start a compilation and let it run throughout the night. My > laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time > :) > This is why I did so much