11 Aug, 2009

1 commit


09 Aug, 2009

1 commit


07 Aug, 2009

1 commit

  • Roland Dreier found that a section that contained only a weak
    function in one of the staging drivers and this caused
    recordmcount.pl to spit out a warning and fail.

    Although it is strange that a driver would have a weak function, and
    this function only be used in one place, it should not be something
    to make recordmcount.pl fail.

    This patch fixes the issue in a simple manner: if only weak
    functions exist in a section, then that section will not be
    recorded.

    Reported-by: Roland Dreier
    Signed-off-by: Steven Rostedt
    Signed-off-by: Ingo Molnar

    Steven Rostedt
     

06 Aug, 2009

1 commit

  • On Wed, 5 Aug 2009, Ingo Molnar wrote:
    > * Dave Airlie wrote:
    >
    > > Hey,
    > >
    > > So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o
    > > breakage by blaming rawhide gcc/binutils as I was using make
    > > V=1and seeing only the compiler chain running,
    >
    > Hm, is this that powerpc related build bug you just reported?

    Well we tracked it down and it is powerpc64 specific.

    Seems that in drivers/hwmon/lm93.c there's a function called:

    LM93_IN_FROM_REG()

    But PPC64 has function descriptors and the real function names (the ones
    you see in objdump) start with a '.'. Thus this in objdump you have:

    Disassembly of section .text:

    0000000000000000 :
    0: 7c 08 02 a6 mflr r0
    4: fb 81 ff e0 std r28,-32(r1)

    The function name used is .LM93_IN_FROM_REG. But gcc considers symbols
    that start with ".L" as a special symbol that is used inside the assembly
    stage.

    The nm passed into recordmcount uses the --synthetic option which shows
    the ".L" symbols (my runs outside of the build did not include the
    --synthetic option, so my older patch worked). We see the function as a
    local.

    Now to capture all the locations that use "mcount" we need to have a
    reference to link into the object file a list of mcount callers. We need a
    reference that will not disappear. We try to use a global function and if
    that does not work, we use a local function as a reference. But to relink
    the section back into the object, we need to make it global. In this case,
    we run objcopy using --globalize-symbol and --localize-symbol to convert
    the symbol into a global symbol, link the mcount list, then convert it
    back to a local symbol.

    This works great except for this case. .L* symbols can not be converted
    into a global symbol, and the mcount section referencing it will remain
    unresolved.

    Reported-by: Dave Airlie
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

05 Aug, 2009

1 commit

  • …nel/git/tip/linux-2.6-tip

    * 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    tracing: Fix missing function_graph events when we splice_read from trace_pipe
    tracing: Fix invalid function_graph entry
    trace: stop tracer in oops_enter()
    ftrace: Only update $offset when we update $ref_func
    ftrace: Fix the conditional that updates $ref_func
    tracing: only truncate ftrace files when O_TRUNC is set
    tracing: show proper address for trace-printk format

    Linus Torvalds
     

04 Aug, 2009

1 commit


30 Jul, 2009

4 commits


24 Jul, 2009

2 commits

  • The value of $offset should be the offset of $ref_func from the
    beginning of the object file. Therefore, we should set both variables
    together.

    This fixes a bug I was hitting on sh where $offset (which is used to
    calcualte the addends for the __mcount_loc entries) was being set
    multiple times and didn't correspond to $ref_func's offset in the object
    file. The addends in __mcount_loc were calculated incorrectly, resulting
    in ftrace dynamically modifying addresses that weren't mcount call
    sites.

    Signed-off-by: Matt Fleming
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Matt Fleming
     
  • Fix the conditional that checks if we already have a $ref_func and that
    the new function is weak. The code as previously checking whether either
    condition was false, and we really need to only update $ref_func is both
    cconditions are false.

    Signed-off-by: Matt Fleming
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Matt Fleming
     

18 Jul, 2009

4 commits


05 Jul, 2009

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes:
    kbuild: finally remove the obsolete variable $TOPDIR
    gitignore: ignore scripts/ihex2fw
    Kbuild: Disable the -Wformat-security gcc flag
    gitignore: ignore gcov output files
    kbuild: deb-pkg ship changelog
    Add new __init_task_data macro to be used in arch init_task.c files.
    asm-generic/vmlinux.lds.h: shuffle INIT_TASK* macro names in vmlinux.lds.h
    Add new macros for page-aligned data and bss sections.
    asm-generic/vmlinux.lds.h: Fix up RW_DATA_SECTION definition.

    Linus Torvalds
     

02 Jul, 2009

1 commit


01 Jul, 2009

1 commit

  • When building with a 4.1.x compiler on powerpc64 (at least) we get this
    error:

    drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict

    This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
    ("fbdev: move logo externs to header file"). This is a partial revert of
    that commit sufficient to not hit the compiler bug.

    Also convert _clut arrays from __initconst to __initdata.

    Sam said:

    Al analysed this some time ago. When we say something is const then
    _sometimes_ gcc annotate the section as const(?) - sometimes not. So if
    we have two variables/functions annotated __*const and gcc decides to
    annotate the section const only in one case we get a section type
    conflict.

    Signed-off-by: Stephen Rothwell
    Cc: Sam Ravnborg
    Cc: Krzysztof Helt
    Cc: Geert Uytterhoeven
    Cc: Kyle McMartin
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Rothwell
     

27 Jun, 2009

2 commits


26 Jun, 2009

1 commit


20 Jun, 2009

4 commits

  • Fix function actual parameter vs. kernel-doc description matching
    so that a warning is not printed when it should not be:

    Warning(include/linux/etherdevice.h:199): Excess function parameter 'addr' description in 'is_etherdev_addr'

    Signed-off-by: Randy Dunlap
    Signed-off-by: Sam Ravnborg

    Randy Dunlap
     
  • Teach kernel-doc to ignore kmemcheck_bitfield_{begin,end} sugar
    so that it won't generate warnings like this:

    Warning(include/net/sock.h:297): No description found for parameter 'kmemcheck_bitfield_begin(flags)'
    Warning(include/net/sock.h:297): No description found for parameter 'kmemcheck_bitfield_end(flags)'

    Signed-off-by: Randy Dunlap
    Signed-off-by: Sam Ravnborg

    Randy Dunlap
     
  • The previous commit (17b1f0de) introduced a slightly broken consolidation
    of the memory text range checking.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Sam Ravnborg

    Mike Frysinger
     
  • Fix the following build error when do 'make htmldocs':

    DOCPROC Documentation/DocBook/debugobjects.xml
    exec /scripts/kernel-doc: No such file or directory
    exec /scripts/kernel-doc: No such file or directory

    Reported-by: Randy Dunlap
    Signed-off-by: WANG Cong
    Acked-by: Randy Dunlap
    Signed-off-by: Sam Ravnborg

    Amerigo Wang
     

19 Jun, 2009

1 commit

  • Enable the use of GCC's coverage testing tool gcov [1] with the Linux
    kernel. gcov may be useful for:

    * debugging (has this code been reached at all?)
    * test improvement (how do I change my test to cover these lines?)
    * minimizing kernel configurations (do I need this option if the
    associated code is never run?)

    The profiling patch incorporates the following changes:

    * change kbuild to include profiling flags
    * provide functions needed by profiling code
    * present profiling data as files in debugfs

    Note that on some architectures, enabling gcc's profiling option
    "-fprofile-arcs" for the entire kernel may trigger compile/link/
    run-time problems, some of which are caused by toolchain bugs and
    others which require adjustment of architecture code.

    For this reason profiling the entire kernel is initially restricted
    to those architectures for which it is known to work without changes.
    This restriction can be lifted once an architecture has been tested
    and found compatible with gcc's profiling. Profiling of single files
    or directories is still available on all platforms (see config help
    text).

    [1] http://gcc.gnu.org/onlinedocs/gcc/Gcov.html

    Signed-off-by: Peter Oberparleiter
    Cc: Andi Kleen
    Cc: Huang Ying
    Cc: Li Wei
    Cc: Michael Ellerman
    Cc: Ingo Molnar
    Cc: Heiko Carstens
    Cc: Martin Schwidefsky
    Cc: Rusty Russell
    Cc: WANG Cong
    Cc: Sam Ravnborg
    Cc: Jeff Dike
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Oberparleiter
     

17 Jun, 2009

13 commits