[Bug binutils/32271] strip leaves unused PT_LOAD segments

[nickc at redhat dot com]

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

--- Comment #4 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Stas Sergeev from comment #3)
Hi Stas,

>> 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?

Sure - if the segment is referencing beyond the of the file then it is a bug. 
But if not then it is more of an unexpected behaviour than a real fault.


>> 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'

Heh!  Well I guess that this is a fair response.  Removing an allocated section
is quite likely to cause problems for the executable.


>> or llvm-strip ?
> 
> Same as binutils: unmapped PT_LOADs.

Well at least the two tools are consistent.

>> 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?

Correct.

> Or is there really an API to access that
> info from application?

No.  In the normal case applications are never expected to be able to access
this information.  There are methods that they could use, but it would be a
hack rather than using a supported API.


> Here's the full problem.
> Those notes are added by build systems.
> For example debian build system adds
> .note.package.

You could always strip these note sections from the object files *before* you
link them together.

> 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. :)

Heresy!  The glibc loader is perfect!  (Well no, it is not, but it is quite
good :-).

> 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.

Have you tried linking with -Ttext=0xNNNNNNNN ?  (And/or --text-segment=X
--rodata-segment=X --ldata-segment=X).

Another possibility is to use your own linker script.  Not only could this
script ensure that sections are loaded into the VA region you want, but you
could also have it discard all of those unwanted debug and note sections too.

Cheers
  Nick

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