[OT?] is there no package containing the raw "vmlinux" kernel image?

[Stefan Bader]

On 07/01/2010 02:53 PM, Chase Douglas wrote:
> On Thu, 2010-07-01 at 08:27 -0400, Robert P. J. Day wrote:
>> On Thu, 1 Jul 2010, Stefan Bader wrote:
>>
>>> Its always hard to tell whether things are detailed enough. Try
>>>
>>> https://wiki.ubuntu.com/Kernel/Dev and there
>>> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter in particular.
>>
>>   great, thanks, i'll check that out, but let me (reluctantly) drag
>> this out for one most post since i think i found what i want.
>>
>>   to recap (and sorry for boring folks with what are trivialities
>> relative to what normally happens on this list), i'm updating a lesson
>> on how to debug a running kernel and loadable modules with simple gdb,
>> and that requires both access to /proc/kcore and a raw vmlinux file
>> that corresponds *exactly* to the running kernel.
>>
>>   if a student of mine can rebuild a new kernel and reboot, then it's
>> trivial.  but in some cases, i know some of my students *don't* have
>> the freedom to reboot the system to get to a new kernel -- they can,
>> however, download source and configure and build to get a vmlinux file
>> that (ideally) would match the running kernel.
>>
>>   from reading:
>>
>> https://help.ubuntu.com/community/Kernel/Compile
>>
>> all i really want is to download the source tree that was used to
>> build the running kernel:
>>
>> $ uname -r
>> 2.6.32-22-generic
>> $
>>
>> at which point i can simply configure based on the appropriate
>> /boot/config file and build, does that make sense?
> 
> I can see two potential issues here:
> 
> 1. The original and the newly built kernels will be different due to the
> build time stamp inserted into the kernel (you can use uname -a to see
> it). Maybe this won't trip up gdb though.
> 
> 2. It cannot be assumed that building a kernel in the same fashion will
> produce the same binary. Even if you build it again on the exact same
> system with the exact same binaries and libraries, gcc is
> nondeterministic when you compile with optimizations. It may or may not
> produce the same output. It probably will, but you can't assume that's
> the case.
> 
I would not think so if the same libraries and gcc versions are used. But this
may or may not be the case. But generally it should be close enough. Still one
needs to keep in mind that there might be subtle differences and the only ways
to track things for sure is to build a kernel, run it and use the produced files
with debug information.

Stefan

> Unfortunately, it seems the only solution is to use the ddebs that are
> produced from the kernel that is shipped. We are still hammering through
> archive bugs as Stefan noted, but one hopes things will only get better
> in the future :).
> 
> -- Chase
>