On Mon, 2015-06-15 at 14:28 -0700, Josh Stone wrote:
CC elfutils-devel, this appears to be a regression. I'm
top-posting my
own findings, but I'll leave the kernel report below...
With elfutils-0.162, it appears that "strip" doesn't reduce the file
size when operating in-place (without -o). This isn't particular to
funny kernel ELF -- I reproduced it on a local stap binary.
My full stap is 31MB. With strip -o, I get a new 2.5MB file. With
strip in-place, stap remains 31MB even though the ELF section data does
indicate all the DWARF sections are gone.
I bisected it to commit 77482c4bf63a.
https://git.fedorahosted.org/cgit/elfutils.git/commit/?id=77482c4bf63a921...
if (elf->parent == NULL
&& (elf->maximum_size == ~((size_t) 0)
|| (size_t) size > elf->maximum_size)
- && unlikely (ftruncate (elf->fildes, size) != 0))
+ && unlikely (posix_fallocate (elf->fildes, 0, size) != 0))
In elf_begin() w/ ELF_C_RDWR, we get maximum_size == ~0, but now this
posix_fallocate can only increase the file size. The later part of
write_file() to reduce the size is only called for maximum_size != ~0.
Yes, you are right. Of course it is the smallest one-liner patch of the
release with the most comments and discussions across multiple lists.
And still people (me) failed to spot the maximum_size == -1 case. Sigh.
Sorry about that.
Simplest probably is to just revert this one patch and do a elfutils
0.163 release with just that (and the translation updates). The issue
that this was preventing (disk full with ELF_C_RDWR_MMAP, ftruncate
appear to succeed, write in memory map causes SIGBUS) is probably less
likely to trigger than this regression.
I have to get me some sleep now. I look over the other options tomorrow.
Cheers,
Mark