Compiler seg faults while building Linux kernel #42
Comments
|
Here's a setup procedure:
|
|
I confirmed this by printing out a message when that method returns a nullptr. Commenting out the call to I suspect we are destroying pieces of the DeclContext by the way we update it. I sent an e-mail to the cfe-dev mailing list asking for advice on how we can safely manipulate the DeclContext's order of a RecordDecl's fields, but no response yet. I've also tried updating our |
|
I built the kernel with I sampled 5 of them randomly. The ones I randomly selected are declaring instances of a struct like so:
Code generation for these structures are causing the Clang compiler to abort. The compiler aborts due to failing this assertion: clang-9: /home/connor/src/llvm-project/llvm/include/llvm/Support/Casting.h:254: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = llvm::PointerType, Y = llvm::Type]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. I'm unable to reproduce this on our simple testing C program with something like this: struct ptrs {
int (* hi)();
int (* bye)();
int (* why)();
} __attribute__((randomize_layout));
static const struct ptrs global = {
.hi = 0,
.bye = 0,
.why = 0
};Here's the list of structures (actually, instances of the structures):
|
I looked at a few examples from the list you provided, and though I didn't look at all of them, they seem to include nested structures as members. Have you tried to reproduce the problem using with a nested structure test? Perhaps even cut-n-paste an actual instance that fails? |
Yes, it compiles cleanly and runs.
Not yet, but I'll start looking through for a structure that fails but that isn't encumbered by a lot of "scaffolding" |
|
Although I haven't quite figured it out, I believe your problem is in The initializer list is created during parsing and uses the pre-randomized order. Perhaps a call to I need to recompile with your code in order to test this, but if this is the case, you should be able to print out an initialized structure with incorrect values without the need to make it assert or crash. |
|
Verified that initialization is busted when reordering fields. Here's a little program that demonstrates the problem. Try it with/without the randomize_layout attribute to see the difference. I'll dig a little deeper, but at this point, you should probably go back to the list and ask for advice on how to deal with designator lists while reordering fields. Richard Smith is probably the right guy to ask. |
|
I don't think messing around with the initializer list creation is a good idea -- probably couldn't permute the field order there anyway. But, if you could attach a map (old_index->new->index) to the RecordDecl when you reorder it, codegen could use the map to match them back up. The key here is that while designator lists can be sparse, the holes get filled in via |
|
Wow, thank you so much for all your help! We'll circle back to implement this. Sincerely appreciate your help diagnosing this. You rock. |
|
You're more than welcome. Looking forward to this patch landing... |
|
Btw, I'm not an authority on which approach should or should not be taken, so before spending a lot of time implementing something, I'd encourage you to seek advice from the list and/or D59254. Again, looking forward to this landing... |
Don't worry, same here.
Absolutely. :-) |
|
Calling |
Kees found this in testing.
I pulled latest changes from LLVM/Clang and applied the ASM goto series. Also applied Randstruct patches.
With Randstruct disabled the kernel builds fine.
With Randstruct enabled the compiler will segfault.
I find this part of the stack trace particularly interesting:
But when I look at that method nothing is glaringly obviously wrong about it. I think there's got to be some corruption in the DeclContext as a result of our rearranging.
The text was updated successfully, but these errors were encountered: