This reverts commit ad7a953c.

And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
            9bb48247

These stripping patches has caused a set of issues:

1) People have reported compatibility issues with binutils due to
   lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
   Reported by: Wenji
2) ccache and distcc no longer works as expeced
   Reported by: Ted, Roland, + others
3) The installed modules increased a lot in size
   Reported by: Ted, Davej + others
Reported-by: NWenji Huang <wenji.huang@oracle.com>
Reported-by: N"Theodore Ts'o" <tytso@mit.edu>
Reported-by: NDave Jones <davej@redhat.com>
Reported-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This patch changes the way __crc_ symbols are being resolved from
using ld to do so to using the assembler, thus allowing these symbols
to be marked local (the linker creates then as global ones) and hence
allow stripping (for modules) or ignoring (for vmlinux) them. While at
this, also strip other generated symbols during module installation.

One potentially debatable point is the handling of the flags passeed
to gcc when translating the intermediate assembly file into an object:
passing $(c_flags) unchanged doesn't work as gcc passes --gdwarf2 to
gas whenever is sees any -g* option, even for -g0, and despite the
fact that the compiler would have already produced all necessary debug
info in the C->assembly translation phase. I took the approach of just
filtering out all -g* options, but an alternative to such negative
filtering might be to have a positive filter which might, in the ideal
case allow just all the -Wa,* options to pass through.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Avoid duplicating long list of options in two places
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Sometimes it is preferable to avoid changes of exported symbol checksums
(to avoid breaking externally provided modules).  When a checksum change
occurs, it can be hard to figure out what caused this change: underlying
types may have changed, or additional type information may simply have
become available at the point where a symbol is exported.

Add a new --reference option to genksyms which allows it to report why
checksums change, based on the type information dumps it creates with the
--dump-types flag.  Genksyms will read in such a dump from a previous run,
and report which symbols have changed (and why).

The behavior can be controlled for an entire build as follows: If
KBUILD_SYMTYPES is set, genksyms uses --dump-types to produce *.symtypes
dump files.  If any *.symref files exist, those will be used as the
reference to check against.  If KBUILD_PRESERVE is set, checksum changes
will fail the build.
Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Impact: cleanup

Sam Ravnborg pointed out that I could condense the code for the parameters of
recordmcount.pl by using an $(if ...) condition.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The recordmcount script requires that the actual arch is passed in.
This works well when ARCH=i386 or ARCH=x86_64 but does not handle the
case of ARCH=x86.

This patch adds a parameter to the function to pass in the number of
bits of the architecture. So that it can determine if x86 should be
run for x86_64 or i386 archs.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CC      scripts/mod/empty.o
/bin/sh: /usr/src/25/scripts/recordmcount.pl: Permission denied

We shouldn't assume that files have their `x' bits set.  There are various
ways in which file permissions get lost, including use of patch(1).

It might not be correct to assume that perl lives in $PATH?
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

I'm seeing when I use separate src/build dirs:

make[3]: *** [arch/x86/kernel/time_32.o] Error 1
/bin/sh: scripts/recordmcount.pl: No such file or directory
make[3]: *** [arch/x86/kernel/irq_32.o] Error 1
/bin/sh: scripts/recordmcount.pl: No such file or directory
make[3]: *** [arch/x86/kernel/ldt.o] Error 1
/bin/sh: scripts/recordmcount.pl: No such file or directory
make[3]: *** [arch/x86/kernel/i8259.o] Error 1
/bin/sh: scripts/recordmcount.pl: No such file or directory

This fixes it.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This patch creates a section in the kernel called "__mcount_loc".
This will hold a list of pointers to the mcount relocation for
each call site of mcount.

For example:

objdump -dr init/main.o
[...]
Disassembly of section .text:

0000000000000000 <do_one_initcall>:
   0:   55                      push   %rbp
[...]
000000000000017b <init_post>:
 17b:   55                      push   %rbp
 17c:   48 89 e5                mov    %rsp,%rbp
 17f:   53                      push   %rbx
 180:   48 83 ec 08             sub    $0x8,%rsp
 184:   e8 00 00 00 00          callq  189 <init_post+0xe>
                        185: R_X86_64_PC32      mcount+0xfffffffffffffffc
[...]

We will add a section to point to each function call.

   .section __mcount_loc,"a",@progbits
[...]
   .quad .text + 0x185
[...]

The offset to of the mcount call site in init_post is an offset from
the start of the section, and not the start of the function init_post.
The mcount relocation is at the call site 0x185 from the start of the
.text section.

  .text + 0x185  == init_post + 0xa

We need a way to add this __mcount_loc section in a way that we do not
lose the relocations after final link.  The .text section here will
be attached to all other .text sections after final link and the
offsets will be meaningless.  We need to keep track of where these
.text sections are.

To do this, we use the start of the first function in the section.
do_one_initcall.  We can make a tmp.s file with this function as a reference
to the start of the .text section.

   .section __mcount_loc,"a",@progbits
[...]
   .quad do_one_initcall + 0x185
[...]

Then we can compile the tmp.s into a tmp.o

  gcc -c tmp.s -o tmp.o

And link it into back into main.o.

  ld -r main.o tmp.o -o tmp_main.o
  mv tmp_main.o main.o

But we have a problem.  What happens if the first function in a section
is not exported, and is a static function. The linker will not let
the tmp.o use it.  This case exists in main.o as well.

Disassembly of section .init.text:

0000000000000000 <set_reset_devices>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   e8 00 00 00 00          callq  9 <set_reset_devices+0x9>
                        5: R_X86_64_PC32        mcount+0xfffffffffffffffc

The first function in .init.text is a static function.

00000000000000a8 t __setup_set_reset_devices
000000000000105f t __setup_str_set_reset_devices
0000000000000000 t set_reset_devices

The lowercase 't' means that set_reset_devices is local and is not exported.
If we simply try to link the tmp.o with the set_reset_devices we end
up with two symbols: one local and one global.

 .section __mcount_loc,"a",@progbits
 .quad set_reset_devices + 0x10

00000000000000a8 t __setup_set_reset_devices
000000000000105f t __setup_str_set_reset_devices
0000000000000000 t set_reset_devices
                 U set_reset_devices

We still have an undefined reference to set_reset_devices, and if we try
to compile the kernel, we will end up with an undefined reference to
set_reset_devices, or even worst, it could be exported someplace else,
and then we will have a reference to the wrong location.

To handle this case, we make an intermediate step using objcopy.
We convert set_reset_devices into a global exported symbol before linking
it with tmp.o and set it back afterwards.

00000000000000a8 t __setup_set_reset_devices
000000000000105f t __setup_str_set_reset_devices
0000000000000000 T set_reset_devices

00000000000000a8 t __setup_set_reset_devices
000000000000105f t __setup_str_set_reset_devices
0000000000000000 T set_reset_devices

00000000000000a8 t __setup_set_reset_devices
000000000000105f t __setup_str_set_reset_devices
0000000000000000 t set_reset_devices

Now we have a section in main.o called __mcount_loc that we can place
somewhere in the kernel using vmlinux.ld.S and access it to convert
all these locations that call mcount into nops before starting SMP
and thus, eliminating the need to do this with kstop_machine.

Note, A well documented perl script (scripts/recordmcount.pl) is used
to do all this in one location.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Setting the option DEBUG_SECTION_MISMATCH will
report additional section mismatch'es but this
should in the end makes it possible to get rid of
all of them.

See help text in lib/Kconfig.debug for details.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

When multiple built-in modules (especially drivers) provide the same
capability, they're prioritized by link order specified by the order
listed in Makefile.  This implicit ordering is lost for loadable
modules.

When driver modules are loaded by udev, what comes first in
modules.alias file is selected.  However, the order in this file is
indeterministic (depends on filesystem listing order of installed
modules).  This causes confusion.

The solution is two-parted.  This patch updates kbuild such that it
generates and installs modules.order which contains the name of
modules ordered according to Makefile.  The second part is update to
depmod such that it generates output files according to this file.

Note that both obj-y and obj-m subdirs can contain modules and
ordering information between those two are lost from beginning.
Currently obj-y subdirs are put before obj-m subdirs.

Sam Ravnborg cleaned up Makefile modifications and suggested using awk
to remove duplicate lines from modules.order instead of using separate
C program.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Cc: Bill Nottingham <notting@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Jon Masters <jonathan@jonmasters.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Introduce ccflags-y, asflags-y and ldflags-y so we soon can
deprecate use of EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
This patch does not touch any in-tree users - thats next round.
Lets get this committed first and then fix the users of the
soon to be deprecated variants next.

The rationale behind this change is to introduce support for
makefile fragments like:

ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG

As a replacement for the uglier:
ifeq ($(CONFIG_WHATEVER_DEBUG),y)
        EXTRA_CFLAGS := -DDEBUG
endif
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

External modules have in a few cases modifed gcc option
by modifying CFLAGS. This has never been documented and
was a bad practice.
With the check to use KBUILD_CFLAGS it will no longer work
so we better error out and tell what was wrong as a service
to the external module users.

This check can be overruled if
KBUILD_NOPEDANTIC is set to something.
Addid this possibility may allow older external
module to build without any code modifications but potentially
only loosing some un-important gcc options.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

These checks has been present for several kernel releases (> 5).
So lets just get rid of them.
With this we no longer check for use of:
EXTRA_TARGETS, O_TARGET, L_TARGET, list-multi, export-objs

There were three remaining in-tree users of O_TARGET in some
unmaintained sh64 code - mail sent to the maintainer + list.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

EXTRA_ARFLAGS have never been used so no need to carry
around on this.
A google search did not reveal any external module
using this either.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Sam Ravnborg pointed out that Documentation/kbuild/makefiles.txt already
says this is what it's for.  This patch makes the reality live up to the
documentation.  This fixes the problem of LDFLAGS_BUILD_ID getting into too
many places.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

A few of the variables used by kbuild has fixed naming.
Make sure we do not pick up random values from the environment.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

To introduce support for source in one directory but output files
in another directory during a non O= build prefix all paths
with $(src) repsectively $(obj).
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Consistently decide when to rebuild a target across all of
if_changed, if_changed_dep, if_changed_rule.
PHONY targets are now treated alike (ignored) for all targets

While add it make Kbuild.include almost readable by factoring out a few
bits to some common variables and reuse this in Makefile.build.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

kbuild used $¤(*F to get filename of target without extension.
This was used in several places all over kbuild, but introducing
make -rR broke his for all cases where we specified full path to
target/prerequsite. It is assumed that make -rR disables old style
suffix-rules which is why is suddenly failed.

ia64 was impacted by this change because several div* routines in
arch/ia64/lib are build using explicit paths and then kbuild failed.

Thanks to David Mosberger-Tang <David.Mosberger@acm.org> for an explanation
what was the root-cause and for testing on ia64.

This patch also fixes two uses of $(*F) in arch/um
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This reverts commit e5c44fd8.

Thanks to Daniel Ritz and Michal Piotrowski for noticing the problem.

Daniel says:

  "[The] reason is a recent change that made modules always shows as
   module.mod.  it breaks modprobe and probably many scripts..besides
   lsmod looking horrible

   stuff like this in modprobe.conf:
        install pcmcia_core /sbin/modprobe --ignore-install pcmcia_core; /sbin/modprobe pcmcia
   makes modprobe fork/exec endlessly calling itself...until oom
   interrupts it"
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Here is a patch that adds a new -T option to genksyms for generating dumps of
the type definition that makes up the symbol version hashes. This allows to
trace modversion changes back to what caused them. The dump format is the
name of the type defined, followed by its definition (which is almost C):

  s#list_head struct list_head { s#list_head * next , * prev ; }

The s#, u#, e#, and t# prefixes stand for struct, union, enum, and typedef.
The exported symbols do not define types, and thus do not have an x# prefix:

  nfs4_acl_get_whotype int nfs4_acl_get_whotype ( char * , t#u32 )

The symbol type defintion of a single file can be generated with:

  make fs/jbd/journal.symtypes

If KBUILD_SYMTYPES is defined, all the *.symtypes of all object files that
export symbols are generated.

The single *.symtypes files can be combined into a single file after a kernel
build with a script like the following:

for f in $(find -name '*.symtypes' | sort); do
    f=${f#./}
    echo "/* ${f%.symtypes}.o */"
    cat $f
    echo
done \
| sed -e '\:UNKNOWN:d' \
      -e 's:[,;] }:}:g' \
      -e 's:\([[({]\) :\1:g' \
      -e 's: \([])},;]\):\1:g' \
      -e 's: $::' \
      $f \
| awk '
/^.#/   { if (defined[$1] == $0) {
            print $1
            next
          }
          defined[$1] = $0
        }
        { print }
'

When the kernel ABI changes, diffing individual *.symtype files, or the
combined files, against each other will show which symbol changes caused the
ABI changes. This can save a tremendous amount of time.

Dump the types that make up modversions
Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

make failed to supply the filename when using make -rR and using $(*F)
to get target filename without extension.
This bug was not reproduceable in small scale but using:
$(basename $(notdir $@)) fixes it with same functionality.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This fixes one of the worst kbuild warts left - the broken dependencies used
to check and regenerate the .config file.  This was done via an indirect
dependency and the .config itself had an empty command, which can cause make
not to reread the changed .config file.

Instead of this we generate now a new file include/config/auto.conf from
.config, which is used for kbuild and has the proper dependencies.  It's also
the main make target now for all files generated during this step (and thus
replaces include/linux/autoconf.h).

This also means we can now relax the syntax requirements for the .config file
and we don't have to rewrite it all the time, i.e.  silentoldconfig only
writes .config now when it's necessary to keep it in sync with the Kconfig
files and even this can be suppressed by setting the environment variable
KCONFIG_NOSILENTUPDATE, so the update can (and must) be done manually.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Add -fverbose-asm to i386 Makefile rule for building .s files.  This makes
the assembler output much more readable for humans.

Suggested by Der Herr Hofrat <der.herr@hofr.at>
Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

genksyms needs to know when a symbol must have a "_" prefex as is
true for a few architectures.
Pass $(ARCH) as commandline argument and hardcode what architectures that
needs this info.
Previous attemt to take it from elfconfig.h was br0ken since elfconfig.h
is a generated file.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed.  This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.

For more details on the incorrect behavior, see:

http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html

Changes in this patch:
  - Keep all targets that are to be marked .PHONY in a variable, PHONY.
  - Add .PHONY: $(PHONY) to mark them properly.
  - Remove any $(PHONY) files from the $? list when determining whether
    targets are up-to-date or not.
Signed-off-by: NPaul Smith <psmith@gnu.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

While the recent change to also escape # symbols when storing C-file
compilation command lines was helpful, it should be in effect for all
command lines, as much as the dollar escaping should be in effect for
C-source compilation commands. Additionally, for better readability and
maintenance, consolidating all the escaping (single quotes, dollars,
and now sharps) was also desirable.
Signed-Off-By: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Move $(CC) support functions to Kbuild.include so they are available
in the kbuild files.
In addition the following was done:
	o as-option documented in Documentation/kbuild/makefiles.txt
	o Moved documentation to new section to match
	  new scope of functions
	o added cc-ifversion used to conditionally select a text string
	  dependent on actual $(CC) version
	o documented cc-ifversion
	o change so Kbuild.include is read before the kbuild file
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This makes things a little bit more reader friendly and gvim is less
confused.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

kbuild failed to locate Makefile for external modules.
This brought to my attention how the variables for directories
have different values in different usage scenarios.

Different kbuild usage scenarios:
make       - plain make in same directory where kernel source lives
make O=    - kbuild is told to store output files in another directory
make M=    - building an external module
make O= M= - building an external module with kernel output seperate from src

Value assigned to the different variables:

           |$(src)          |$(obj) |$(srctree)        |$(objtree)
make       |reldir to k src |as src |abs path to k src |abs path to k src
make O=    |reldir to k src |as src |abs path to k src |abs path to output dir
make M=    |abs path to src |as src |abs path to k src |abs path to k src
make O= M= |abs path to src |as src |abs path to k src |abs path to k output

path to kbuild file:

make       | $(srctree)/$(src), $(src)
make O=    | $(srctree)/$(src)
make M=    | $(src)
make O= M= | $(src)

From the table above it can be seen that the only good way to find the
home directory of the kbuild file is to locate the one of the two variants
that is an absolute path. If $(src) is an absolute path (starts with /)
then use it, otherwise prefix $(src) with $(srctree).
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

kbuild failed to locate Kbuild.include.
Teach kbuild how to find Kbuild files when using make O=...
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
---

Kbuild.include is a placeholder for definitions originally present in
both the top-level Makefile and scripts/Makefile.build.
There were a slight difference in the filechk definition, so the most videly
used version was kept and usr/Makefile was adopted for this syntax.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
---

From: Matthew Wilcox <matthew@wil.cx>
I inadvertently built a tree as root and then rebuilt it as a user.  I
got a lot of prompts ...

mv: overwrite `drivers/char/drm/drm_auth.o', overriding mode 0644?

Using mv -f fixes that.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Adding quotation handling to rule_cc_o_c in scripts/Makefile.build as used
elsewhere.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!