Re: strings

Re: strings

[Don Hughes]

On 12 Jan 2005 at 12:30, Jason wrote:

> keep in mind that the spirit of this community is based upon
> volunteer effort and everyone pitching in however they can to
> help better the community as a whole.

Absolutely, and very appreciated.  But I did not read the 
previous posts as a demand, but more of frustration.  There are 
many of us who are not hackers, and for whom netfilter is only a 
small part of the job.  It can be frustrating to get a hundred 
reasons why you should not be doing something that, for whatever 
reason, you need to do anyway.

And, yes, it can be also be frustrating to answer the same 
question over and over and over; but maybe that points to a 
different issue in that the tutorials or documentation needs to 
be modified. Searching the archives and getting 0 or 2000 hits is 
not helpful.


..don  

support at microtechniques.com
White Plains, NY

strings

[Benjamin Herrenschmidt]

Hi folks !

I just noticed, as I was digging into (yet another) unrelated llvm
problem with my code, that sparse-llvm fails to compile something that
has a statement such as:

static char *foo = "Foo !\n";

It pukes in output_data(), where we have initializer non-NULL and
initializer->type is EXPR_STRING. So we hit the default: case which is
an assert(0);

Now a trivial "fix" below doesn't quite work:

diff --git a/sparse-llvm.c b/sparse-llvm.c
index 9226a21..f151939 100644
--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -1181,6 +1181,12 @@ static LLVMValueRef output_data(LLVMModuleRef module, struct symbol *sym)
 				initial_value = output_data(module, sym);
 			break;
 		}
+		case EXPR_STRING: {
+			const char *s = initializer->string->data;
+
+			initial_value = LLVMConstString(strdup(s), strlen(s) + 1, true);
+			break;
+		}
 		default:
 			assert(0);
 		}

That has two interesting effects. First, if llvm is compiled with asserts,
it pukes claiming that the initializer is of the wrong type. Now that's
odd because as far as I can tell, the type is an array of i8 ... and it
works if you don't build the asserts in llvm.

Mind you, I had that problem with a different program, which was using
the various "InContext" variants of the various functions rather than
the global context ones... because at one point I was using the global
context for one of the LLVMInt8Type and that made it fail (again worked
fine without asserts).

Looks like the assert internally to LLVM is a pointer comparison of
Type * so it has to resolve to -exactly- the same type object internally,
pretty touchy. Maybe throwing a cast might help.

The second effect however is that the result is not nice:

  .../...

@"<noident>" = private global [7 x i8] c"Foo !\0A\00"
@foo = private global i8* @"<noident>"

  .../...

I haven't quite manage to coerce it to just have a single @foo = <something>
so it looks like we need to separately define the storage (the string)
and foo as a pointer to it, unless I missed something.

I tried to use the same construct we use in pseudo_to_value() (I factored
it out) but that results in worse output, where it now names the string
(.str<N>) but then creates a <noident> ptr and then assigns that to foo...

LLVM is harder than it seems :-)

Cheers,
Ben.