linux-kernel - Re: special handle of scripts/kconfig/zconf.tab.o

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 19 Aug 2017 21:42:40 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Cao jin <caoj.fnst@...fujitsu.com>
Cc:     Michal Marek <mmarek@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Sam Ravnborg <sam@...nborg.org>
Subject: Re: special handle of scripts/kconfig/zconf.tab.o

Hi.
(+CC Sam)

2017-08-15 20:02 GMT+09:00 Cao jin <caoj.fnst@...fujitsu.com>:
> Masahiro-san,
>
> I have a question about make *config. In scripts/kconfig/Makefile, there
> is following statement:
>
> $(obj)/zconf.tab.o: $(obj)/zconf.lex.c $(obj)/zconf.hash.c
>
> and the $(obj)/zconf.{tab,hash,lex}.c match the rule in Makefile.lib:
>
> $(obj)/%: $(src)/%_shipped
>         $(call cmd,shipped)
>
> and cmd_shipped just transform the _shipped file to .c via `cat`.
>
> And zconf.tab.c includes several *other* .c files which make the whole
> process a little obscure, because there are not corresponding .o files
> for the *other* .c files.
>
> My questions is: Does this special handling has other meanings that I
> may miss? Or just legacy.

This convention had existed before I joined the kernel development,
so I am not sure about the historical background.

The following is my understanding.
(I hope Sam and Michal will correct me if I am wrong.)

The difference between with/without _shipped is,
zconf.{tab,hash,lex}.c_shipped reside under $(srctree),
whereas zconf.{tab,hash,lex}.c under $(objtree).

zconf.{tab,hash,lex}.c are generated by
bison, gperf, flex, respectively.
(zconf.y, zconf.gperf, zconf.l are *real* source files)

So, Kbuild likes to copy zconf.{tab,hash,lex}.c to $(objtree)
to treat them as generated files, I think.

> Because a straightforward way in my mind would be:
>
> rename zconf.{tab,hash,lex}.c_shipped to zconf.{tab,hash,lex}.c, then
> has following in the Makefile
>
> common-objs := zconf.tab.o zconf.hash.o zconf.lex.o util.o etc...
> conf-objs := conf.o $(common-objs)
>

This is possible.

I think Kbuild developers chose to put them in $(objtree)
because they are not essentially source files.

The location of C files affect the include search path.

See line 208 of scripts/kconfig/Makefile:

# generated files seem to need this to find local include files
HOSTCFLAGS_zconf.lex.o  := -I$(src)
HOSTCFLAGS_zconf.tab.o  := -I$(src)

Here, we have one more question.

Can we generate zconf.{tab,hash,lex}.c from zconf.{y,gperf,l}
instead of from *_shipped?

This is also possible, technically.
But, I do not know if it is acceptable to have
more external tool dependencies.
(So, I sent RFC patches to hear more opinions.)

-- 
Best Regards
Masahiro Yamada