by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Hactar
    @HactarCE
    Make sure to call function.verify() before executing
    or module.verify()
    Alberto
    @0X1A
    Yeah, reading some docs here and looking at main there I can see that there simply is no terminating instruction since I wasn't building a return!
    Daniel Kolsoi
    @TheDan64
    Ack, we should probably call module.verify() in get_function_address and bubble that up to get_function if the former (a safe function) can segfault from that
    Alberto
    @0X1A
    Maybe, but what's the cost of verify? May not want to perform checks on each function/function address get when the user is really meant to do that
    Daniel Kolsoi
    @TheDan64
    Not sure, but it's either that or make the function unsafe
    Daniel Kolsoi
    @TheDan64
    Or maybe we should call verify on the module when you create the execution engine, so that it's only done once rather than on each function lookup
    Manos Pitsidianakis
    @epilys
    @TheDan64 we will need DW_ATE enum for specifying types in src/debug_info.rs but llvm doesn't export them, instead they are defined in the DWARF standards
    should inkwell export them or leave it to the user?
    i guess there can be an enum for each DWARF version that can Into<u32> and let the user pass raw u32if they wish
    Manos Pitsidianakis
    @epilys
    interesting thought I had about the Basic Block does not have terminator error, this type of error can be caught on the type level with the builder pattern.
    Daniel Kolsoi
    @TheDan64
    That's... and interesting question
    Figuring out all of the possible dwarf version values sounds like a pain
    I think if DW_ATE is actually an integer then we should just leave it up to the user
    If it's a C-enum then we don't want to potentially give it invalid values...
    I forget if it's safe to give C an int where it expects an enum. Maybe?
    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