Re: Producing assembly language listing of kernel



Gil Hamilton <gil_hamilton@xxxxxxxxxxx> wrote:

What exactly are you trying to discover? I suspect you'll be better off
just trying to read and understand the C code. Generally, one only
wants assembly output in order to discover specific things about the
instructions being generated by the compiler in specific cases.

I am working on a patch that will allow me to specify my cpu capabilities
manually, and disable cpuinfo detection from the kernel. This is to enable
machines with slight differences in the cpu makeup to behave in a
coherent manner using lowest common denominator. I also want to remove certain
instructions such as cmov,cpuid,rdtsc and p6_nop sequences from the
kernel. These instructions are not valid on some of my machines.

Unfortunately, I am not an experienced C programmer, or an experienced
Linux kernel hacker, but I know assembly language extremely well.

The sections of code that I am looking at contain lots of conditional
compilation directives, and make use of inline assembly language.

I don't know how this inlining works in relation to the rest of the
code. However, if I could see the assembled instructions together with
the call to the inline code, I would be able to make sense of this.

The listing file would also tell me which sections of conditionally
compiled code are being incorporated into the kernel during build.

Basically, I need to see how the whole lot meshes together, so that I
can make appropriate modifications.

However, if you want to look at code that is generated in specific
cases, you don't even need to recompile. Just load up the kernel under
the appropriate version of gdb and type "x/10i <symbol_name>" to
disassemble on the fly.

Can I do this on a vmlinuz image? I have a third party supplied kernel
that I would also like to examine.

Of course you'll have to figure out where the
code you want to look at actually resides; pretty much all of the code
that resides in headers is in the form of macros or "static inline"
functions and hence it gets pulled into the functions where it's
referenced, so you need to disassemble the non-inline function in order
to see that code.

Again, a listing would really help here.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

.