[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#748577: arch/x86/tools/relocs.c per_cpu_load_addr missing "static"



Control: tag -1 upstream

On Sun, 2014-05-18 at 16:48 +0100, Michael Tautschnig wrote:
> Package: linux
> Version: 3.14.4-1
> Usertags: goto-cc
> 
> During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
> and pbuilder) the build failed with the following error. Please note that we
> use our research compiler tool-chain (using tools from the cbmc package), which
> permits extended reporting on type inconsistencies at link time.
> 
> [...]
>   HOSTCC  arch/x86/tools/relocs_32.o
>   HOSTCC  arch/x86/tools/relocs_64.o
>   HOSTCC  arch/x86/tools/relocs_common.o
>   HOSTLD  arch/x86/tools/relocs
> 
> file /srv/jenkins-slave/workspace/sid-goto-cc-linux/linux-3.14.4/arch/x86/tools/relocs.c line 698: error: conflicting types for variable "per_cpu_load_addr"
> old definition in module relocs_32 file /srv/jenkins-slave/workspace/sid-goto-cc-linux/linux-3.14.4/arch/x86/tools/relocs.c line 698
> unsigned int
> new definition in module relocs_64 file /srv/jenkins-slave/workspace/sid-goto-cc-linux/linux-3.14.4/arch/x86/tools/relocs.c line 698
> unsigned long int
> scripts/Makefile.host:127: recipe for target 'arch/x86/tools/relocs' failed
> make[6]: *** [arch/x86/tools/relocs] Error 64
> /srv/jenkins-slave/workspace/sid-goto-cc-linux/linux-3.14.4/arch/x86/Makefile:179: recipe for target 'archscripts' failed
> make[5]: *** [archscripts] Error 2
> 
> Unlike other variables in relocs.c, per_cpu_load_addr is not marked static:
> 
> http://sources.debian.net/src/linux/3.11.8-1/arch/x86/tools/relocs.c?hl=698#L698
> 
> As, however, the type used in its declaration is different for
> relocs_32/relocs_64, a type conflict (of the thus duplicate definition) arises.
> The standard linker will pick either of the two definitions, possibly resulting
> in the 32 bit (unsigned int) version being used, which would cause arbitrary
> values to be overwritten when assigning to per_cpu_load_addr in a 64 bit
> context.

I think you are mistaken.  The standard linker, GNU ld, is documented to
use the maximum size of multiple 'common' symbol definitions.

Nevertheless, in C terms this is obviously undefined behaviour and I
doubt that the program was intended to depend on this.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
                      - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: