This object file is used for probing target properties, so disable
clang LTO for it to avoid producing LLVM IR instead.
Bug: 62093296
Change-Id: I43998647ead629a0fd5f5c4d2a96898521d61c7c
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Largely redundant code is used in different places to generate C headers
from offset information extracted from assembly language output.
Consolidate the code in Makefile.lib and use this instead.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked from commit ebf003f0cfb3705e60d40dedc3ec949176c741af)
Change-Id: I5871044d15e78b717f74359bcf6a4712e9fb36ea
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Upstream has an updated version of this patch that fixes UM breakage.
This reverts commit b9b5e80496.
Change-Id: Id34765d177ec5325432302b7c6b1c825afceabdf
Signed-off-by: Greg Hackmann <ghackmann@google.com>
When using clang with -no-integerated-as clang will use the gnu assembler instead
of the integrated assembler. However clang will still perform asm error checking
before sending the inline assembly language to gas.
The generation of asm-offsets from within C code is dependent on gcc's blind
passing of whatever is in asm() through to gas. Arbirary text is
passed through which is then modified by a sed script into the appropriate .h
and .S code. Since the arbitrary text is not valid assembly language, clang fails.
This can be fixed by making the arbitrary text into an ASM comment and then
updating the sed scripts accordingly to work as expected.
This solution works for both gcc and clang.
Change-Id: I158d15288adef50f175e107e19ff336fc0ab2e37
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Cc: Jan Moskyto Matejka <mq@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: Tom Gundersen <teg@jklm.no>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
For one, there's no point in the respective pieces to be rebuilt
unconditionally on each and every rebuild.
Second there's no need to invent a custom rule for generating the .s
file from the .c source - we can simply use the generic rule here.
And finally, $(obj) should be used to refer to files in the build tree
(rather than spelling out the subdirectory).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Make sure devicetable-offsets.h is cleaned in the scripts/mod directory
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Use the target compiler to compute the offsets for the fields of the
device_id structures, so that it won't be broken by different alignments
between the host and target ABIs.
This also fixes missing endian corrections for some modaliases.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The next commit will require the use of MODULE_SYMBOL_PREFIX in
.tmp_exports-asm.S. Currently it is mixed in with C structure
definitions in "asm/module.h". Move the definition of this arch option
into Kconfig, so it can be easily accessed by any code.
This also lets modpost.c use the same definition. Previously modpost
relied on a hardcoded list of architectures in mk_elfconfig.c.
A build test for blackfin, one of the two MODULE_SYMBOL_PREFIX archs,
showed the generated code was unchanged. vmlinux was identical save
for build ids, and an apparently randomized suffix on a single "__key"
symbol in the kallsyms data).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Mike Frysinger <vapier@gentoo.org> (blackfin)
CC: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
