Hi,
.debug_arange analysis shows that there's a lot of holes in .text. Turns out these are NOP runs (for alignment purposes, I guess). First, is it OK for the producer to leave NOP runs alone? If yes, dwarflint shouldn't warn about it, but then there is a problem of how to detect this.
I think we can assume that the compiler actually emits literal "NOP" instructions for padding purposes (i.e. not one of these contraptions that look like they do something). But most of the time, we won't even see contents of .text, will we? We are dealing with stripped debuginfo-only files. Or are we going to do our debuginfo transformation business on full files?
PM
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Petr Machata wrote:
First, is it OK for the producer to leave NOP runs alone?
Yes.
If yes, dwarflint shouldn't warn about it, but then there is a problem of how to detect this.
These areas are not covered by any symbol. In correctly written code the size associated with a symbol extends to just past the last instruction. In asm code this is done using the .size pseudo-op. Take a look at what the compiler generates.
I think we can assume that the compiler actually emits literal "NOP" instructions for padding purposes (i.e. not one of these contraptions that look like they do something).
Actually, the NOPs are not emitted literally. They are the result of an .align pseudo-op in asm code and aligning of sections in the linker.
But most of the time, we won't even see contents of .text, will we? We are dealing with stripped debuginfo-only files. Or are we going to do our debuginfo transformation business on full files?
Actually, I think we'll have to do this work before stripping. The reason is simple: the stripping has to be reversable. That's not possible after the compression.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Actually, I think we'll have to do this work before stripping. The reason is simple: the stripping has to be reversable. That's not possible after the compression.
I don't know why you think that. The transformed DWARF in a .debug file can be recombined with the stripped file using unstrip, there's no problem.
Thanks, Roland
Em Wed, Feb 04, 2009 at 05:16:18PM +0100, Petr Machata escreveu:
Hi,
.debug_arange analysis shows that there's a lot of holes in .text. Turns out these are NOP runs (for alignment purposes, I guess). First, is it OK for the producer to leave NOP runs alone? If yes, dwarflint shouldn't warn about it, but then there is a problem of how to detect this.
I think we can assume that the compiler actually emits literal "NOP" instructions for padding purposes (i.e. not one of these contraptions that look like they do something). But most of the time, we won't even see contents of .text, will we? We are dealing with stripped debuginfo-only files. Or are we going to do our debuginfo transformation business on full files?
ftrace in the Linux kernel uses NOPs for leaving space for dynamic code patching, to insert calls to mcount, etc.
I guess the alternatives code in the Linux kernel also uses NOPs to provide a dynamicly optimizable kernel depending on the processor the kernel is booted on.
If curious, take a look at:
arch/x86/include/asm/nops.h arch/x86/include/asm/alternative.h arch/um/sys-x86_64/shared/sysdep/system.h Look at rdtsc.
in the Linux sources :-)
- Arnaldo
.debug_arange analysis shows that there's a lot of holes in .text. Turns out these are NOP runs (for alignment purposes, I guess). First, is it OK for the producer to leave NOP runs alone? If yes, dwarflint shouldn't warn about it, but then there is a problem of how to detect this.
Like I just posted: don't try anyway.
I think we can assume that the compiler actually emits literal "NOP" instructions for padding purposes (i.e. not one of these contraptions that look like they do something).
Nope. The assembler or linker decides what to fill with, and they can be clever with fancy multi-byte nop instructions on x86.
But most of the time, we won't even see contents of .text, will we? We are dealing with stripped debuginfo-only files. Or are we going to do our debuginfo transformation business on full files?
It can be done both ways. In the rpm build process as eventually revamped, I think it will be rolled in with the stripping step, so will have full originals at hand. But dwarflint should not depend on looking at code sections at all, I think.
Thanks, Roland
Roland McGrath wrote:
.debug_arange analysis shows that there's a lot of holes in .text. Turns out these are NOP runs (for alignment purposes, I guess). First, is it OK for the producer to leave NOP runs alone? If yes, dwarflint shouldn't warn about it, but then there is a problem of how to detect this.
Like I just posted: don't try anyway.
Right, reading it now. So the rest of the question is irrelevant, I'll just turn off the hole-finder, which is the reason I needed that.
PM
elfutils-devel@lists.fedorahosted.org
-
Arnaldo Carvalho de Melo -
Petr Machata -
Roland McGrath -
Ulrich Drepper