llvm-cbe generates missing l_fptr_1 from .ll ouput from clang++-10 (plzip-1.9 dec_stdout.c)

[makise-homura]

Say, we have LLVM 10.0.0, and just have built llvm-cbe in current directory.

Trying to build dec_stdout.cc from plzip-1.9 with lzlib-1.12:

wget -q http://download.savannah.gnu.org/releases/lzip/lzlib/lzlib-1.12.tar.gz
wget -q http://download.savannah.gnu.org/releases/lzip/plzip/plzip-1.9.tar.gz
tar xf plzip-1.9.tar.gz
tar xf lzlib-1.12.tar.gz
clang++-10 -S -emit-llvm -g -Iplzip-1.9 -Ilzlib-1.12 -o dec_stdout.ll plzip-1.9/dec_stdout.cc
./llvm-cbe dec_stdout.ll
gcc-10 -Wno-builtin-declaration-mismatch -Wno-address-of-packed-member -c -o dec_stdout.o dec_stdout.cbe.c

I have the following output then (among the message caused by #138):

dec_stdout.cbe.c:466:78: error: unknown type name ‘l_fptr_1’
  466 | uint32_t pthread_create(uint64_t*, struct l_struct_union_OC_pthread_attr_t*, l_fptr_1*, uint8_t*) __ATTRIBUTELIST__((nothrow));
      |                                                                              ^~~~~~~~
/usr/src-remote/llvm/llvm-cbe/build-10/tools/llvm-cbe/plzip-1.9/dec_stdout.cc: In function ‘_Z10dec_stdoutiiiRK12Pretty_printiiRK10Lzip_index’:
/usr/src-remote/llvm/llvm-cbe/build-10/tools/llvm-cbe/plzip-1.9/dec_stdout.cc:309:10: warning: implicit declaration of function ‘pthread_create’ [-Wimplicit-function-declaration]
  309 |     }
      |          ^

If we grep dec_stdout.cbe.c for l_fptr_1, we'll figure out it's not declared (and, since it's in declaration of pthread_create(), this function appears undeclared after a while):

uint32_t pthread_create(uint64_t*, struct l_struct_union_OC_pthread_attr_t*, l_fptr_1*, uint8_t*) __ATTRIBUTELIST__((nothrow));

I expected hacking first call to clang++-10 with something like -pthread, -include /usr/include/pthread.h would help with that; but I had no success (and about LLVMMul_uov, I really have no idea--there is no such declaration in the whole /usr/include).

Of course, calling clang to compile instead of generate .ll succeeds. Called like this:

clang++-10 -S -c -g -Iplzip-1.9 -Ilzlib-1.12 -o dec_stdout.o plzip-1.9/dec_stdout.cc

[hikari-no-yume]

I recently fixed another issue involving missing l_fptr types: #101

I wonder if this is a similar type of issue.

Edit: In fact it sounds very similar, so I am surprised it is happening. I will probably have a look at it soon.

[makise-homura]

@hikari-no-yume Looks like so. Still reproducible in current master.

By the way, I figured out simple examples how to get these errors.

This one (pthread_test.c):

#include <pthread.h>
void* helloWorld(void *args) { return NULL; }
int main()
{
    pthread_t thread;
    int status_addr;
    pthread_create(&thread, NULL, helloWorld, NULL);
    pthread_join(thread, (void**)&status_addr);
    return 0;
}

Building (specifying or skipping -pthread on call to either clang, gcc, or both does not matter):

clang-10 -S -emit-llvm -g -o pthread_test.ll pthread_test.c
./llvm-cbe pthread_test.ll
gcc-10 pthread_test.cbe.c -o pthread_test

Other one is now moved to #138, as you proposed.

Clang and gcc versions:

clang version 10.0.0-4ubuntu1 Target: x86_64-pc-linux-gnu Thread model: posix
gcc-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0

[hikari-no-yume]

Thanks for the reproducers. The pthread one works for getting the unknown type name error for me, even though I am on macOS. I guess this works because pthreads is a common POSIX API. (Edit: #135 should fix it.)

I haven't tried the second reproducer yet. If it is not too much hassle, could you make a separate issue for that one? Though the errors may seem similar, I think it is likely to be caused by a different part of the CBE code.

[makise-homura]

Sorry for late reply, I was on kind of vacation and had no access to host where I was experimenting with this. Now I got back to this. Created #138, and edited this issue to focus on pthread-related stuff.

[makise-homura]

By the way, I tried the branch from #135, and it does not reproduce there both with pthread_test.c (a call to gcc-10 should be with -pthread option added), and with original dec_stdout.cc (but latter still suffers from #138).