Re: [lkcd-devel] Re: [kbuild-devel] sorting out the kerntypes mess
On Dunnersdag 10 Februar 2005 17:51, Christoph Hellwig wrote: Linking it into vmlinux would increase vmlinux size, which is exactly what the Kerntypes approach is trying to avoid. Well, building the whole kernel with -gstabs or similar will enlarge the binary by factor ten or more, which should definitely be avoided. The kerntypes.o file is very small compared to vmlinux, so it doesn't hurt much to link them together. Also, the debug information is stripped out of the zImage file and therefore doesn't affect many uses at all. OTOH, it should also be possible to just drop the debug information in the vmlinux link step and create a separate binary with only the debug data from the same input files, using a different linker script. Arnd pgpIW5q1q6Qe7.pgp Description: signature
Re: [lkcd-devel] Re: [kbuild-devel] sorting out the kerntypes mess
On Sun, Jan 30, 2005 at 11:16:35PM +0100, Arnd Bergmann wrote: On S?nndag 30 Januar 2005 18:37, Christoph Hellwig wrote: So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. Currenly it's called Kerntypes, which would make sense to be kept, but else yes. How about simply linking the kerntypes files into vmlinux? AFAIK, lcrash is able to use vmlinux with stabs information instead of a separate kerntypes file. Supporting this could be as simple as putting obj-y += $(kerntypes-y) $(kerntypes-y): CFLAGS += $(KERNTYPES_FLAGS) into scripts/Makefile.build, although I haven't tried that. Linking it into vmlinux would increase vmlinux size, which is exactly what the Kerntypes approach is trying to avoid. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] sorting out the kerntypes mess
Hi Christoph The various dumping projects like lkcd and the s390 VM dump require debug information for the kernel, and they're using a mechanism that compiles a small file containing nothing but includes for interesting types into a Kerntypes file for the debugger. Unfortunately the various current ways to generate it are a little messy and thus we don't have support for it in mainline. As a clean way to implement it and supports multiple files that can be linked into Kerntypes (e.g. arch or subsystem-specific) I'd like to suggest the following additions to the kernel build system: kerntypes-y += object files KERNTYPEFLAGS += compile flags Which build all objects listed in kerntypes-y with the CFLAGS from KERNTYPEFLAGS (defaulting to CFLAGS) into a top-level Kerntypes file. First trying to understand exactly what you want. So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. There are a few (solveable) issue with this. - kbuild needs to keep track of all kerntypes.y files. This is done for the kernel with a built-in.o file that links all .o files for a given dir and subdirs. In this was the final link is just a few built-in.o files (+ a bitmore). - Addind kerntypes-y would make kbuild infrastructure even more scary than today. There most be some very good reasons to add more complexity to the current implmentation. Maybe a simpler solution could be deployed: One file for all of the kernel located in kernel/kerntypes.o Then the arch makefile can link in their relevant files in a post processing step like when we build bzImage and the like. This requires much less support in common kbuild files. Unfortunately I'm a little lost in the current kbuild infrastructure so some help would be very welcome. If we can agree on something I will give it a try. Sam --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] sorting out the kerntypes mess
On Sun, Jan 30, 2005 at 06:34:48PM +0100, Sam Ravnborg wrote: First trying to understand exactly what you want. So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. Currenly it's called Kerntypes, which would make sense to be kept, but else yes. There are a few (solveable) issue with this. - kbuild needs to keep track of all kerntypes.y files. This is done for the kernel with a built-in.o file that links all .o files for a given dir and subdirs. In this was the final link is just a few built-in.o files (+ a bitmore). - Addind kerntypes-y would make kbuild infrastructure even more scary than today. There most be some very good reasons to add more complexity to the current implmentation. Maybe a simpler solution could be deployed: One file for all of the kernel located in kernel/kerntypes.o Then the arch makefile can link in their relevant files in a post processing step like when we build bzImage and the like. This requires much less support in common kbuild files. That could work aswell. Note that e.g. for s390 most of the additional bites are for drivers/s390/ datastructures which would make sense to be done with a drivers/s390/kerntypes.c file, but if it's really that bad let's go for your scheme. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
