Re: Missing extern "C" in count-one-bits.h?

[Simon Marchi]

On 2020-02-21 3:59 p.m., Paul Eggert wrote:
> On 2/20/20 12:15 PM, Simon Marchi wrote:
>> The disagreement between the symbol names between count-one-bits.o and 
>> arm-get-next-pcs.o
>> seems to show that there is a missing `extern "C"` in the count-one-bits.h 
>> header?
> 
> Thanks, I'll take your word for it. (I don't use C++.) I installed the 
> attached patch into Gnulib. Apparently these modules have been used by C code 
> only, until now.

Thanks, that does the job.

I'll try to provide a minimal reproducer next time, I just haven't learned yet
how to use gnulib in a standalone way (outside of what GDB uses).

>> And apparently, gcc decided to compile the definition in the header and 
>> include
>> it in arm-get-next-pcs.o, while clang did not.  Is that the compiler's 
>> choice,
>> or is it because the macros and preprocessor conditionals in count-one-bits.h
>> evaluated to something different for the two compilers?
> 
> It's a compiler's choice whether a function is inlined. When I call 
> count_one_bits in C, gcc -O2 doesn't create a function for count_one_bits in 
> the calling module; it simply issues the popcnt insn, or calls the 
> appropriate GCC library function on platforms that don't have a popcnt insn. 
> Perhaps you were compiling with some other level of optimization, or perhaps 
> C++ does this differently; but regardless of how the compiler does it the 
> resulting code is supposed to work of course.

I indeed build without optimizations, to be able to debug, it's likely that
clang with optimizations would also reduce that to just popcnt.

Anyway, thanks for the help, I'll go work on updating GDB's gnulib import!

Simon