Repository navigation
Recover type information #190
Description
Currently, some type information (e.g. const, volatile) regarding variables is lost.
For example, this source code
struct foo {
int x;
};
typedef struct foo foo_t;
int main(void) {
const volatile foo_t **a = 0;
void *b = a;
}roundtrips to:
unsigned int main();
struct struct_foo {
unsigned int x;
};
unsigned int main() {
struct struct_foo **a; // lost const volatile
unsigned char *b; // was void* before
a = (void *)0U;
b = (unsigned char *)a;
return 0U;
}It would be nice to recover the original type information when possible.
Activity
frabert commentedon Oct 22, 2021
So one problem I stumbled upon while working on this is the following: currently, all local declarations are at the top, and initialization follows. This is not valid in the case of
constvariables, e.g.is valid, but
is not
pgoodman commentedon Oct 22, 2021
Is there an opportunity here? For example, the
constqualifier in debug info is telling us "this is assigned once." There will be a declref or something in the code on the assignment statement. Theconstis thus a kind of hint to us that "hey, we /could/ do the decl and assignment at the site of this assignment.I'm not sure how to guarantee that valid code is produced. For example, if the scoping ends up wrong, then that means we possibly already admitted undefined behaviour into the code (by having a read-before-write of
a).frabert commentedon Oct 29, 2021
chartypes pose a bit of an issue: all of the other integral types are eithersignedorunsigned, withsignedbeing the default when not specified.charis different, in thatcharis "its own thing", separate fromsigned charandunsigned char.For example,
The issue is that debug info only either specify
signedorunsignedfor integral types, with no possibility of expressing a "plain"char. This causes lots of warnings for e.g. stringspgoodman commentedon Oct 29, 2021
Perhaps from the triple and the data layout we can get whether or not char is signed on the platform? I know in LanguageOptions there's a way to force signed or unsigned char.
frabert commentedon Oct 29, 2021
According to https://llvm.org/docs/LangRef.html#langref-datalayout we do not have something to tell us whether
chars are signed or unsigned by default, but even if we did... we'd still need to specify the signedness in the C code, otherwise we would not be guaranteed to have the same semantics on platforms with different signedness, once re-compiled... or am I missing something?At that point the only issue becomes deciding whether global strings (which do not have debug info attached, from a first glance) are
signed char*orunsigned char*, but that could be solved via a command line argument or something like thatpgoodman commentedon Oct 29, 2021
Do you see
"omnipotent char"show up anywhere in debug info? We might be able to see that and usechar. There isCharIsSigned, and here is how LLDB infers this.frabert commentedon Oct 30, 2021
Yes,
"omnipotent char"does show up as part of TBAA attributes onloadandstoreinstructions.I've tried searching for something but couldn't really grasp what that means.
pgoodman commentedon Oct 30, 2021
Perhaps it's actually a sort of joke type for pointers. Perhaps if we know if it's meant to be a
char, but want to hedge against signed/unsigned, we could have a typedef liketypedef signed char char_tortypedef unsigned char char_t, or have achar_tand auchar_t.