Eric Lee / smarc-fsl-linux-kernel

14 Sep, 2019

1 commit

24 Jun, 2019

1 commit

  • a222061b8   genksyms: Teach parser about 128-bit built-in types ... Browse Code »

    __uint128_t crops up in a few files that export symbols to modules, so
    teach genksyms about it and the other GCC built-in 128-bit integer types
    so that we don't end up skipping the CRC generation for some symbols due
    to the parser failing to spot them:

    | WARNING: EXPORT symbol "kernel_neon_begin" [vmlinux] version
    | generation failed, symbol will not be versioned.
    | ld: arch/arm64/kernel/fpsimd.o: relocation R_AARCH64_ABS32 against
    | `__crc_kernel_neon_begin' can not be used when making a shared
    | object
    | ld: arch/arm64/kernel/fpsimd.o:(.data+0x0): dangerous relocation:
    | unsupported relocation

    Reported-by: Arnd Bergmann
    Signed-off-by: Will Deacon
    Signed-off-by: Masahiro Yamada

    Will Deacon
     

05 Jan, 2017

1 commit

  • d920f7c66   genksyms: Fix segfault with invalid declarations ... Browse Code »

    Do not try to recover too early and segfault when parsing invalid
    declarations such as

    echo 'int (int);' | scripts/genksyms/genksyms
    echo 'int a, (int);' | scripts/genksyms/genksyms
    echo 'extern void *__inline_memcpy((void *), (const void *), (__kernel_size_t));' | scripts/genksyms/genksyms

    The last one was a real-life bug with
    include/asm-generic/asm-prototypes.h on x86_64.

    Reported-and-tested-by: Borislav Petkov
    Signed-off-by: Michal Marek

    Michal Marek
     

29 Nov, 2016

1 commit

  • 0efdb2282   kbuild/genksyms: handle va_list type ... Browse Code »

    genksyms currently does not handle va_list. Add the __builtin_va_list
    keyword as a type. This reduces the amount of syntax errors thrown,
    but so far no export symbol has a type with a va_list argument, so
    there is currently no bug in the end result.

    Note: this patch does not regenerate shipped parser files.

    Signed-off-by: Nicholas Piggin
    Signed-off-by: Michal Marek

    Nicholas Piggin
     

20 Aug, 2015

1 commit

  • 1c722503f   genksyms: Duplicate function pointer type definitions segfault ... Browse Code »

    I noticed that genksyms will segfault when it sees duplicate function
    pointer type declaration when I placed the same function pointer
    definition in two separate headers in a local branch as an intermediate
    step of some refactoring. This can be reproduced by piping the following
    minimal test case into `genksyms -r /dev/null` or alternatively, putting
    it into a C file attempting a build:

    typedef int (*f)();
    typedef int (*f)();

    Attaching gdb to genksyms to understand this failure is useless without
    changing CFLAGS to emit debuginfo. Once you have debuginfo, you will
    find that the failure is that `char *s` was NULL and the program
    executed `while(*s)`. At which point, further debugging requires
    familiarity with compiler front end / parser development.

    What happens is that flex identifies the first instance of the token "f"
    as IDENT and the yacc parser adds it to the symbol table. On the second
    instance, flex will identify "f" as TYPE, which triggers an error case
    in the yacc parser. Given that TYPE would have been IDENT had it not
    been in the symbol table, the the segmentaion fault could be avoided by
    treating TYPE as IDENT in the affected rule.

    Some might consider placing identical function pointer type declarations
    in different headers to be poor style might consider a failure to be
    beneficial. However, failing through a segmentation fault makes the
    cause non-obvious and can waste the time of anyone who encounters it.

    Signed-off-by: Richard Yao
    Acked-by: Madhuri Yechuri
    Signed-off-by: Michal Marek

    Richard Yao
     

04 Apr, 2014

1 commit

  • dc5332406   genksyms: fix typeof() handling ... Browse Code »

    Recent increased use of typeof() throughout the tree resulted in a
    number of symbols (25 in a typical distro config of ours) not getting a
    proper CRC calculated for them anymore, due to the parser in genksyms
    not coping with several of these uses (interestingly in the majority of
    [if not all] cases the problem is due to the use of typeof() in code
    preceding a certain export, not in the declaration/definition of the
    exported function/object itself; I wasn't able to find a way to address
    this more general parser shortcoming).

    The use of parameter_declaration is a little more relaxed than would be
    ideal (permitting not just a bare type specification, but also one with
    identifier), but since the same code is being passed through an actual
    compiler, there's no apparent risk of allowing through any broken code.

    Otoh using parameter_declaration instead of the ad hoc
    "decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to
    be handled rather than just plain ones and pointers to plain ones.

    Signed-off-by: Jan Beulich
    Cc: Michal Marek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Beulich
     

11 Oct, 2011

2 commits

17 Mar, 2011

1 commit

  • e37ddb825   genksyms: Track changes to enum constants ... Browse Code »

    Enum constants can be used as array sizes; if the enum itself does not
    appear in the symbol expansion, a change in the enum constant will go
    unnoticed. Example patch that changes the ABI but does not change the
    checksum with current genksyms:

    | enum e {
    | E1,
    | E2,
    |+ E3,
    | E_MAX
    | };
    |
    | struct s {
    | int a[E_MAX];
    | }
    |
    | int f(struct s *s) { ... }
    | EXPORT_SYMBOL(f)

    Therefore, remember the value of each enum constant and
    expand each occurence to . The value is not actually
    computed, but instead an expression in the form
    (last explicitly assigned value) + N
    is used. This avoids having to parse and semantically understand whole
    of C.

    Note: The changes won't take effect until the lexer and parser are
    rebuilt by the next patch.

    Signed-off-by: Michal Marek
    Acked-by: Sam Ravnborg

    Michal Marek
     

25 Nov, 2010

1 commit

01 Aug, 2008

1 commit

  • 94aa3d716   kbuild: genksyms parser: fix the __attribute__ rule ... Browse Code »

    We are having two kinds of problems with genksyms today: fake checksum
    changes without actual ABI changes, and changes which we would rather like
    to ignore (such as an additional field at the end of a structure that
    modules are not supposed to touch, for example).

    I have thought about ways to improve genksyms and compute checksums
    differently to avoid those problems, but in the end I don't see a
    fundamentally better way. So here are some genksyms patches for at least
    making the checksums more easily manageable, if we cannot fully fix them.

    In addition to the bugfixes (the first two patches), this allows genksyms
    to track checksum changes and report why a checksum changed (third patch),
    and to selectively ignore changes (fourth patch).

    This patch:

    Gcc __attribute__ definitions may occur repeatedly, e.g.,

    static int foo __attribute__((__used__))
    __attribute__((aligned (16)));

    The genksyms parser does not understand this, and generates a syntax error.
    Fix this case.

    Signed-off-by: Andreas Gruenbacher
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Sam Ravnborg

    Andreas Gruenbacher
     

13 Oct, 2007

1 commit

  • 3550a516d   kbuild: __extension__ support in genksyms (fix unknown CRC warning) ... Browse Code »

    Recently the __extension__ keyword has been introduced in the kernel.
    Teach genksyms about this keyword so it can generate correct CRC for
    exported symbols that uses a symbol marked __extension__.
    For now only the typedef variant:

    __extension__ typedef ...

    is supported.
    Later we may add more variants as needed.

    This patch contains the actual source file changes. The
    following patch will hold modifications to the generated
    files (*_shipped) and only after the second patch the fix
    has effect.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

27 Dec, 2005

1 commit

  • a89a0a235   kbuild: Fix genksyms handling of DEFINE_PER_CPU(struct foo_s *, bar); ... Browse Code »

    This is a one-line change to parse.y.
    To take advantage of this the scripts/genksyms/*_shipped files needs to
    be rebuild - this is the next patch.

    When a .c file contains:
    DEFINE_PER_CPU(struct foo_s *, bar);

    the .cpp output looks like:
    __attribute__((__section__(".data.percpu"))) __typeof__(struct foo_s *) per_cpu__bar;

    With the existing parse.y, the value inside the paranthesis of
    __typeof__() does not evaluate as a type_specifier and therefore
    per_cpu__bar does not get assigned a type for genksyms which results in
    the EXPORT_PER_CPU_SYMBOL() not generating a CRC value.

    I have compared the Modules.symvers with and without this
    patch and for ia64's defconfig, the only change is:
    Before 0x00000000 per_cpu____sn_nodepda vmlinux
    After 0x9d3f3faa per_cpu____sn_nodepda vmlinux

    per_cpu____sn_nodepda was the original source of my problems.

    Signed-off-by: Robin Holt
    Signed-off-by: Sam Ravnborg

    Robin Holt
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds