bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/20815] throw errors for invalid load segment


From: nickc at redhat dot com
Subject: [Bug ld/20815] throw errors for invalid load segment
Date: Wed, 16 Nov 2016 17:29:49 +0000

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

--- Comment #8 from Nick Clifton <nickc at redhat dot com> ---
Hi Ma,

(In reply to ma.jiang from comment #6)
>   First of all , The elf specification does not say very clear about the
> first load segment. In my edition 
> "Tool Interface Standard (TIS)
> Executable and Linking Format (ELF) 
> Specification
> Version 1.2",
> there is such a sentence:
> "The first text page contains the ELF header, the program header table, and
> other information." (in the i386 sections ).

True - but ... this is describing the *example* layout shown just above (Figure
A-4).  It is not talking about a mandated file layout.


> moreover,the elf specification said
> "If it is present,it must precede any loadable segment entry" about the
> PT_PHDR segment.

True - but we are not dealing with a PR_PHDR segment that is in the wrong
place, we are dealing with a program header that is not in any segment at all.
At least in the case of the test executable I built the program header starts
at 64 bytes into the file and occupies 56 bytes.  The first segment however
starts at 0x200000 bytes into the file, followed by a second one at 0x400001
bytes. 


>   Secondly, About the executable generated by the linker, I do NOT think it
> is a valid ELF format.The elf specification said "it may occur only if the
> program header table is part of the memory image of the program" about the
> PT_PHDR segment. Thank goodness,this time the specification said things
> clear. The generated  executable has a PT_PHDR,but the segment is NOT a part
> of memory image of the program.

No - you are confusing two things.  The program header, which is a region of
the file containing entries in the Elf32_Phdr or Elf64_Phdr format, and a
program segment which is a region of the file described by one of the entries
in the program header itself.  Now an ELF executable *may* elect to make the
program header be part of one of these program segments, in which case that
segment gets the PT_PHDR type and it should be mapped into memory when the
executable is loaded.  But - the ELF standard does not require that the program
headers be contained in a program segment.  They can be placed outside of any
segment, and at any offset into the file.  The only requirement is that, if
they exist, they must be indexed by the e_phoff field in the ELF file header,
and - by implication - that they do not conflict with any of the other data in
the file.

So a valid ELF binary can have a program header that is not contained in the
first program segment, provided that it is not any of the other segments
either.  Hence the binary being produced by your test case is a valid ELF
binary.

Of course I realise that this does not help you with the case you encountered -
the linker silently producing a non-working binary.  But at issue here is that
the linker script being used was broken, and if you are using linker scripts
then you really need to know what you are doing, and to expect that you will
have to do some deep debugging when things do not work out as planned.  I am
sorry, but I really think that in this case the linker cannot be expected to
diagnose the problem for you.

Cheers
  Nick

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]