Re: [PATCH 1/1] x86, relocs: add function attributes to die()

[Nicolas Iooss <nicolas.iooss_linux@m4x.org>]

On 03/09/16 17:16, Nilay Vaish wrote:
> On 3 September 2016 at 09:50, Nicolas Iooss <nicolas.iooss_linux@m4x.org> wrote:
>>
>>     arch/x86/tools/relocs.c:460:5: error: format specifies type 'int'
>>     but the argument has type 'Elf64_Xword' (aka 'unsigned long')
>>     [-Werror,-Wformat]
>>                                     sec->shdr.sh_size);
>>                                     ^~~~~~~~~~~~~~~~~
>>     arch/x86/tools/relocs.c:464:5: error: format specifies type 'int'
>>     but the argument has type 'Elf64_Off' (aka 'unsigned long')
>>     [-Werror,-Wformat]
>>                                     sec->shdr.sh_offset, strerror(errno));
>>                                     ^~~~~~~~~~~~~~~~~~~
>>
>> To support both 32-bit and 64-bit modes, add casts to long types and use
>> %lu and %ld to format the numbers.
>>
> 
> Nicolas,  should not just changing the format specifiers fix the
> problem?  How do those type casts help?

The problem is that I did not found a simple format which would make
both arch/x86/tools/relocs_32.o and arch/x86/tools/relocs_64.o build
without any warning. Here are the types:

* When compiling relocs_32.c, sec->shdr.sh_size is of type Elf32_Word
(unsigned int) and sec->shdr.sh_offset is Elf32_Off (unsigned int).
* When compiling relocs_64.c, sec->shdr.sh_size is Elf64_Xword (long
long unsigned int when the compiler is in 32-bit mode, long unsigned int
in 64-bit mode) and sec->shdr.sh_offset is Elf64_Off (same real type as
sec->shdr.sh_size).

I though that casting everything to long integers was fine but now I
have realized this does not take into account compiling relocs_64.c on a
32-bit host system (where HOSTCC compiles in 32-bit mode and long
integers are 32-bit wide).

A possible solution would be using format definitions from <inittypes.h>
like PRIu32, PRIu64... in relocs.c depending on the file being compiled
(relocs_32.c or relocs_64.c). What would you think of such a solution?

-- Nicolas