30 Dec, 2020

1 commit

  • [ Upstream commit 135b4957eac43af2aedf8e2a277b9540f33c2558 ]

    $(error-if,...) is expanded to an empty string. Currently, it relies on
    eval_clause() returning xstrdup("") when all attempts for expansion fail,
    but the correct implementation is to make do_error_if() return xstrdup("").

    Fixes: 1d6272e6fe43 ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Sasha Levin

    Masahiro Yamada
     

09 Jun, 2019

1 commit


28 Dec, 2018

1 commit


21 Dec, 2018

1 commit


28 Jun, 2018

1 commit

  • If buf[-1] just happens to hold the byte 0x0A, then nread can wrap around
    to (size_t)-1, leading to invalid memory accesses.

    This has caused segmentation faults when trying to build the latest
    kernel snapshots for i686 in Fedora:
    https://bugzilla.redhat.com/show_bug.cgi?id=1592374

    Signed-off-by: Jerry James
    [alexpl@fedoraproject.org: reformatted patch for submission]
    Signed-off-by: Alexander Ploumistos
    Signed-off-by: Masahiro Yamada

    Jerry James
     

29 May, 2018

9 commits

  • When using a recursively expanded variable, it is a common mistake
    to make circular reference.

    For example, Make terminates the following code:

    X = $(X)
    Y := $(X)

    Let's detect the circular expansion in Kconfig, too.

    On the other hand, a function that recurses itself is a commonly-used
    programming technique. So, Make does not check recursion in the
    reference with 'call'. For example, the following code continues
    running eternally:

    X = $(call X)
    Y := $(X)

    Kconfig allows circular expansion if one or more arguments are given,
    but terminates when the same function is recursively invoked 1000 times,
    assuming it is a programming mistake.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • The special variables, $(filename) and $(lineno), are expanded to a
    file name and its line number being parsed, respectively.

    Suggested-by: Randy Dunlap
    Signed-off-by: Masahiro Yamada
    Reviewed-by: Kees Cook

    Masahiro Yamada
     
  • Syntax:
    $(info,)
    $(warning-if,,)
    $(error-if,, part is y.

    Kconfig does not implement the lazy expansion as used in the 'if'
    'and, 'or' functions in Make. In other words, Kconfig does not
    support conditional expansion. The unconditional 'error' function
    would always terminate the parsing, hence would be useless in Kconfig.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Kees Cook

    Masahiro Yamada
     
  • Support += operator. This appends a space and the text on the
    righthand side to a variable.

    The timing of the evaluation of the righthand side depends on the
    flavor of the variable. If the lefthand side was originally defined
    as a simple variable, the righthand side is expanded immediately.
    Otherwise, the expansion is deferred. Appending something to an
    undefined variable results in a recursive variable.

    To implement this, we need to remember the flavor of variables.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • The previous commit added variable and user-defined function. They
    work similarly in the sense that the evaluation is deferred until
    they are used.

    This commit adds another type of variable, simply expanded variable,
    as we see in Make.

    The := operator defines a simply expanded variable, expanding the
    righthand side immediately. This works like traditional programming
    language variables.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Now, we got a basic ability to test compiler capability in Kconfig.

    config CC_HAS_STACKPROTECTOR
    def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n)

    This works, but it is ugly to repeat this long boilerplate.

    We want to describe like this:

    config CC_HAS_STACKPROTECTOR
    bool
    default $(cc-option,-fstack-protector)

    It is straight-forward to add a new function, but I do not like to
    hard-code specialized functions like that. Hence, here is another
    feature, user-defined function. This works as a textual shorthand
    with parameterization.

    A user-defined function is defined by using the = operator, and can
    be referenced in the same way as built-in functions. A user-defined
    function in Make is referenced like $(call my-func,arg1,arg2), but I
    omitted the 'call' to make the syntax shorter.

    The definition of a user-defined function contains $(1), $(2), etc.
    in its body to reference the parameters. It is grammatically valid
    to pass more or fewer arguments when calling it. We already exploit
    this feature in our makefiles; scripts/Kbuild.include defines cc-option
    which takes two arguments at most, but most of the callers pass only
    one argument.

    By the way, a variable is supported as a subset of this feature since
    a variable is "a user-defined function with zero argument". In this
    context, I mean "variable" as recursively expanded variable. I will
    add a different flavored variable in the next commit.

    The code above can be written as follows:

    [Example Code]

    success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n)
    cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)

    config CC_HAS_STACKPROTECTOR
    def_bool $(cc-option,-fstack-protector)

    [Result]
    $ make -s alldefconfig && tail -n 1 .config
    CONFIG_CC_HAS_STACKPROTECTOR=y

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • This accepts a single command to execute. It returns the standard
    output from it.

    [Example code]

    config HELLO
    string
    default "$(shell,echo hello world)"

    config Y
    def_bool $(shell,echo y)

    [Result]

    $ make -s alldefconfig && tail -n 2 .config
    CONFIG_HELLO="hello world"
    CONFIG_Y=y

    Caveat:
    Like environments, functions are expanded in the lexer. You cannot
    pass symbols to function arguments. This is a limitation to simplify
    the implementation. I want to avoid the dynamic function evaluation,
    which would introduce much more complexity.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • This commit adds a new concept 'function' to do more text processing
    in Kconfig.

    A function call looks like this:

    $(function,arg1,arg2,arg3,...)

    This commit adds the basic infrastructure to expand functions.
    Change the text expansion helpers to take arguments.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • To get access to environment variables, Kconfig needs to define a
    symbol using "option env=" syntax. It is tedious to add a symbol entry
    for each environment variable given that we need to define much more
    such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
    in Kconfig.

    Adding '$' for symbol references is grammatically inconsistent.
    Looking at the code, the symbols prefixed with 'S' are expanded by:
    - conf_expand_value()
    This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
    - sym_expand_string_value()
    This is used to expand strings in 'source' and 'mainmenu'

    All of them are fixed values independent of user configuration. So,
    they can be changed into the direct expansion instead of symbols.

    This change makes the code much cleaner. The bounce symbols 'SRCARCH',
    'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

    sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE'
    should be replaced with an environment variable.

    ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
    without '$' prefix.

    The new syntax is addicted by Make. The variable reference needs
    parentheses, like $(FOO), but you can omit them for single-letter
    variables, like $F. Yet, in Makefiles, people tend to use the
    parenthetical form for consistency / clarification.

    At this moment, only the environment variable is supported, but I will
    extend the concept of 'variable' later on.

    The variables are expanded in the lexer so we can simplify the token
    handling on the parser side.

    For example, the following code works.

    [Example code]

    config MY_TOOLCHAIN_LIST
    string
    default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

    [Result]

    $ make -s alldefconfig && tail -n 1 .config
    CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Kees Cook

    Masahiro Yamada