Force __builtin_va_list to be a char* in any architecture?

Hi all,

Is there any way to force __builtin_va_list to always be a char*, regardless of the architecture?

We are using clang as a frontend in our project and our analysis relies on the fact that __builtin_va_list is a char* on 64 bits architecture as well, but we keep getting:

-TypedefDecl 0x4148c78 <> implicit referenced __builtin_va_list ‘struct __va_list_tag [1]’
-ConstantArrayType 0x4148c20 'struct __va_list_tag [1]' 1 -RecordType 0x4148aa0 ‘struct __va_list_tag’
`-Record 0x4148a10 ‘__va_list_tag’

I’ve tried several different combinations of defines but to no avail.

In case it is not possible, we could submit a patch to add an option to force that on clang. A bit of an overkill given that we would be the only users (I think).

Best,

Hi Mikhail,

I’m not aware of any option to do that, and I don’t think such an option could work for AArch64 without completely changing the ABI. For AArch64, __builtin_va_list is a struct with 5 members, which is needed because arguments can be passed in a mixture of integer and floating-point registers, and on the stack, so a single pointer can’t store all of the necessary state.

Oliver

I apologize if this seems rude, but my initial reaction is that you should not rely on invariants that do not hold true in practice. :slight_smile: In any case, you are already clearly aware that this assumption creates portability problems, and I don’t seek to assign blame.

I don’t believe we have such an option, and I don’t think we would be open to adding one, since generally we try to discourage the proliferation of alternative ABI variants.

We don’t actually want to add an option to clang, I phrased that incorrectly.

We use libtooling to generate the program AST; clang is only the frontend to our tool.

We have no intent to break the ABI, or to expose such flag to the command line. If we indeed need a flag to achieve this, it would be an option when creating the ASTContext.

I apologize if this seems rude, but my initial reaction is that you should not rely on invariants that do not hold true in practice. :slight_smile: In any case, you are already clearly aware that this assumption creates portability problems, and I don’t seek to assign blame.

Yeah, we are trying to force the type whenever we can but it ends up introducing inconsistencies in the AST :confused: