Clang tooling and cross compiled code bases

I have an issue where I'm trying to use a libTooling based refactoring tool on a codebase that is intended for cross-compilation. I have hacked together means to create a compile_commands.json, but the tool is ignoring -triple and -internal-isystem and therefore getting the sizes of many basic types wrong since my compile host is 64 bit and the target isn't.

Is there a straightforward way of resolving this?

Andrew

I have an issue where I'm trying to use a libTooling based refactoring tool on a codebase that is intended for cross-compilation. I have hacked together means to create a compile_commands.json, but the tool is ignoring -triple and -internal-isystem and therefore getting the sizes of many basic types wrong since my compile host is 64 bit and the target isn't.

Is there a straightforward way of resolving this?

I'd say: it's a bug :slight_smile: Is there an easy way to reproduce this in a
small example?

Cheers,
/Manuel

I have an issue where I'm trying to use a libTooling based refactoring tool on a codebase that is intended for cross-compilation. I have hacked together means to create a compile_commands.json, but the tool is ignoring -triple and -internal-isystem and therefore getting the sizes of many basic types wrong since my compile host is 64 bit and the target isn't.

Is there a straightforward way of resolving this?

I'd say: it's a bug :slight_smile: Is there an easy way to reproduce this in a
small example?

I'll try to construct one. Don't hold your breath, this is a background job.

Andrew

Ok, I did get time, so here we go. Given compile_commands.json containing (obviously, change paths as appropriate):

[
    {
        "command": "clang -fno-signed-char -c -o foo.o foo.c",
        "directory": "/home/andrewm/source/hack/minimal-clang-cc-problem",
        "file": "/home/andrewm/source/hack/minimal-clang-cc-problem/foo.c",
    },
]

and foo.c in the appropriate place containing:

#include <stdio.h>
#include <stdint.h>

void oinker(char *it) {
  printf("%s\n", it);
}

int main(int argc, char **argv) {
  uint64_t foo;
  uint8_t oink = "oink";

  oinker(oink);
  return 0;
}

$ clang-check -p=/home/andrewm/source/hack/minimal-clang-cc-problem/ /home/andrewm/source/hack/minimal-clang-cc-problem/foo.c
Processing: /home/andrewm/source/hack/minimal-clang-cc-problem/foo.c.
warning: argument unused during compilation: '-fno-signed-char'
foo.c:12:10: warning: passing 'uint8_t [5]' to parameter of type 'char *' converts between pointers to integer types with different sign [-Wpointer-sign]
  oinker(oink);
         ^~~~
foo.c:4:19: note: passing argument to parameter 'it' here
void oinker(char *it) {
                  ^
1 warning generated.

I would argue that -fno-signed-char should be respected in this situation.

The same sort of thing applies to many arguments, including -triple (but not -target) and -isystem-internal.

Andrew

When I try to compile this (no tooling involved, just plain clang):
$ ~/build/llvm/bin/clang -c t2.c -fno-signed-char
clang-3: warning: argument unused during compilation: '-fno-signed-char'
<...>

According to chandlerc the right way to pass this to clang is to use
-funsigned-char. Unfortunately that doesn't make the code snippet
compile either:
$ ~/build/llvm/bin/clang -c t2.c -funsigned-char
t2.c:12:10: warning: passing 'uint8_t [5]' to parameter of type 'char
*' converts between pointers to integer types with different sign
[-Wpointer-sign]
<...>

So, that doesn't really seem to be a reduction of the problem you're seeing.

-internal-isystem (I assume you meant that instead of
"-isystem-internal") is a red herring, too - it shouldn't be in a
compilation database, it's an internal flag.

Cheers,
/Manuel

When I try to compile this (no tooling involved, just plain clang):
$ ~/build/llvm/bin/clang -c t2.c -fno-signed-char
clang-3: warning: argument unused during compilation: '-fno-signed-char'
<...>

According to chandlerc the right way to pass this to clang is to use
-funsigned-char. Unfortunately that doesn't make the code snippet
compile either:
$ ~/build/llvm/bin/clang -c t2.c -funsigned-char
t2.c:12:10: warning: passing 'uint8_t [5]' to parameter of type 'char
*' converts between pointers to integer types with different sign
[-Wpointer-sign]
<...>

So, that doesn't really seem to be a reduction of the problem you're seeing.

-internal-isystem (I assume you meant that instead of
"-isystem-internal") is a red herring, too - it shouldn't be in a
compilation database, it's an internal flag.

Sure is, but for some reason I couldn't use just -isystem. I guess I should revisit that problem.

Context is, the compilation database is synthetic; the project compiles with gcc, but I have to manufacture a compilation database for the benefit of static analysis and refactoring tools.

Optimally your build system would do that for you - what build system
are you using?

Cheers,
/Manuel