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]
Message-ID: <CAK7LNATGwrMBsaps1oVOi_21R8jzTadeWSwaK1dA8nMaJs7KpQ@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ