by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Manos Pitsidianakis
    @epilys
    @TheDan64 it's a typedef: typedef unsigned LLVMDWARFTypeEncoding
    to make this safe, DIBuilder could have a DWARF version parameter (DebugInfoBuilder<Dwarf3>) that also sets up the version metadata in the module and provide enums for each version, along with unsafe methods to pass raw integers
    Daniel Kolsoi
    @TheDan64
    I mean, in practice that's still an integer
    But hmm. That might work
    mloc
    @mloc
    I might be going at this the wrong way, but is there a way to get a pointervalue from a vectorvalue?
    specifically I want a pointed to a static string, so I was looking at context.const_string, but that only gives me a vectorvalue
    looking at other llvm stuff, it looks like getelementptr might do what I want, but I don't see that used in inkwell anywhere.
    Manos Pitsidianakis
    @epilys
    @mloc GEP is exactly what you want, yes
    mloc
    @mloc
    ohhh, it's abbreviated to GEP, right :sweat_smile:
    hm. build_gep can only take a pointer, not a vector
    there is a comment saying it should work for arrays too though, I guess that's what I need..
    Daniel Kolsoi
    @TheDan64
    I think array is what you're looking for, not vectors
    I wonder if LLVM even lets you GEP into a vector...
    But anyway you typically get a pointer to an array by allocating it either on the stack or heap
    ie build_array_alloca/build_array_malloc
    Then you can GEP into that
    Daniel Kolsoi
    @TheDan64
    hmm const_string does return a vector..
    Manos Pitsidianakis
    @epilys
    @TheDan64 thanks for your review comments. I think I fixed most if not all your suggestions. Can you tell me what should I do for the coverage check? Make a runnable test under the tests/ dir that generates actual IR with debug metadata?
    Hactar
    @HactarCE
    Should I .delete() all my FunctionValues after I'm done with them, or is dropping the Module sufficient?
    Daniel Kolsoi
    @TheDan64
    @HactarCE dropping should be sufficient
    @epilys Correct. Either a single test that tests everything (if that's much easier) or multiple that focus on specific portions of the new changes
    It's also important to write some tests where we fall validation due to invalid debug ir. This should improve confidence that those scenarios don't produce UB as memory corruption will likely crop up now or in the future
    Manos Pitsidianakis
    @epilys
    @TheDan64 thanks, I know what to do now. Debugging has a really big interface so I want to get this basic stuff out of the way first.
    Hactar
    @HactarCE

    I have a StructType that I want to get the size_of, so I called .size_of().unwrap() on that StructType and got this IntValue:

    IntValue { int_value: Value { name: "", address: 0x1a3e494d910, is_const: true, is_null: false, is_undef: false, llvm_value: "i64 mul nuw (i64 ptrtoint (i64* getelementptr (i64, i64* null, i32 1) to i64), i64 2)", llvm_type:  "i64" } }

    It says is_const: true, but when .get_zero_extended_constant() and .get_sign_extended_constant() both return None. Is there something else I should be doing to get the size of this struct?

    (I'm trying to allocate space for this struct and fill it with values from the calling Rust code using Vec<u8>, but I need to know how much space to allocate.)

    Daniel Kolsoi
    @TheDan64
    It might be because LLVM has const and constant which are two different things...
    IIRC constant is a compile time value
    You can check that with IntValue::is_constant_int
    I suppose we should probably update the IntValue debug to list both of those

    IntValue::is_const docs say:

    Constants includes values that are not known at compile time, for example the address of a function casted to an integer.

    IntValue::is_constant_int:

    ConstantInt only includes values that are known at compile time.

    LLVM is so confusing sometimes...
    Daniel Kolsoi
    @TheDan64
    So I assume if the extended constant methods are returning None then LLVM doesn't have a compile-time value to give you
    Either that or there's a bug somewhere
    Daniel Kolsoi
    @TheDan64
    I think const is more like an immutable runtime value (like the docs above say, an address of a function)
    Hactar
    @HactarCE
    Ah ok
    Hactar
    @HactarCE
    I found TargetData::get_store_size(), which I think does what I want. (https://stackoverflow.com/questions/14608250/how-can-i-find-the-size-of-a-type) Thanks!
    mloc
    @mloc
    is there any way to build a (const) GEP on an ArrayValue right now?
    or will that need an inkwell change
    urg. nevermind, again, got my head in a loop
    Sameer Rahmani
    @lxsameer
    hey folks, quick and silly question, is inkwell an active project ? how much of the LLVM api does it cover ?
    mloc
    @mloc
    is there a way to build an arbitrary intrinsic?
    specifically @llvm.pow.f32
    mloc
    @mloc
    is it acceptable to just add an fn with the correct name + types?
    there is LookupIntrinsicID + GetIntrinsicDeclaration but they don't seem necessary if you can do the overloading yourself
    (and it's not exposed by inkwell)
    Daniel Kolsoi
    @TheDan64
    @lxsameer it is indeed active. It covers most of the C API but there are still some gaps.
    @mloc I think you can add a fn with the right name and types so long as it's linked correctly. Newer versions of LLVM have a specific intrinsic getter method which we don't currently support (thanks for reminding me!)
    Sameer Rahmani
    @lxsameer
    @TheDan64 sorry to ask this silly question, but what's you plan for the future of this library ? basically i'm in doubt to use it or not because i'm afraid that this library might not get updates and fall behind llvm halfway through the project
    Daniel Kolsoi
    @TheDan64
    I definitely plan to continue maintaining inkwell and never just abandon it. I see the worst-case scenario (assuming I'm still alive lol) is that I don't have time to add new changes myself, but would still make time to review and accept changes from the community. There are a couple of companies using inkwell in production so they do occasionally submit PRs.
    The biggest blocker to inkwell 0.1.0 is rust-lang/cargo#2980 and there doesn't seem to be any resolution in sight but we do have / will have stopgap crates for specific llvm versions as they release. Adding support for a new LLVM version usually takes a bit of time and effort though