[Bug binutils/32271] strip leaves unused PT_LOAD segments

[stsp at users dot sourceforge.net]

https://sourceware.org/bugzilla/show_bug.cgi?id=32271

--- Comment #3 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Thanks for such a detailed reply!
Its really helpful.

(In reply to Nick Clifton from comment #2)
> Agreed, although this is probably an enhancement rather than a bug.

Having stalled PT_LOAD segment
is most likely a bug. It probably
refers to wrong offsets, or even
past EOF? Or am I missing something
that would make it still "somewhat"
valid?

> Have you tried using eu-strip (from the elfutils project)

Tried just now:
$ eu-strip --strip-debug -R '.note.*' tmp.elf 
eu-strip: Cannot remove allocated section '.note.gnu.property'

So... it refuses to remove, leaving
the file at least in a sane state.
I believe binutils `strip` leaves a
corrupted state.

> or llvm-strip ?

Same as binutils: unmapped PT_LOADs.


> > Also I wonder why the segment that contains
> > .note sections is PT_LOAD? Is this really
> > needed?
> 
> Because they are needed and used.  At least by ld.so on Linux boxes.
> The notes contain information about the architecture extensions needed
> by the application that is being loaded and the loader makes sure that
> these are available before starting to run the code.

I guess its used by glibc, not an application?
Or is there really an API to access that
info from application?

> > I have my own elf loader, and it
> > gets confused by this all.
> 
> It would probably be worth your while enhancing your loader so that it
> can cope with these segments.  Even if it just ignores them.  It will
> make things simpler in the long run.

Here's the full problem.
Those notes are added by build systems.
For example debian build system adds
.note.package.
I am using --section-start switches for
all "allocated" sections to move them to
non-standard location, but if they are
added behind my back, then they have the
default location. When some sections are
moved and some not, you end up with unloadable
ELF because total VA space became too large.
All loaders (even the one from glibc) estimate
the total VA space by subtracting minimal
address from maximal address, but in this case
such estimation fails.
So its not like I can deal with such ELFs,
at least until I want my loader to be smarter
than the one in glibc. :)

The possible work-around can be if you tell
me a magic option with which I can just change
the default VA address, which seems to be
0x8048000 right now. Then I can drop those
horrible --section-start tricks.

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.