Not enough room for program headers (problem with 2.11.92.0.5)

Not enough room for program headers (problem with 2.11.92.0.5)

[Stephan Kulow]

Hi!

I tried latest binutils and also included the patch H . J . Lu posted 
tonight. But I still have a problem with the build of linux-kernel (2.4.10)

The documentation for this ld error I honestly don't understand, it talks 
about that the ldscript shouldn't use SIZEOF_HEADERS, but I didn't 
change anything in that. I updated binutils from 2.11.90.0.31 and there
it worked, so I'm not sure if this a bug or if I misconfigured binutils.

Greetings, Stephan

gcc -D__ASSEMBLY__ -D__KERNEL__-I/usr/src/linux/include  -traditional -c 
head.S
gcc -D__KERNEL__ -I/usr/src/linux/include  -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer 
-pipe -mpreferred-stack-boundary=2 -march=i686 -Os -c misc.c
ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
ld: bvmlinux: Not enough room for program headers (allocated 2, need 3)
ld: final link failed: Bad value
make[2]: *** [bvmlinux] Error 1

Re: Not enough room for program headers (problem with 2.11.92.0.5)

[H . J . Lu]

On Mon, Oct 15, 2001 at 06:02:18PM +0200, Stephan Kulow wrote:
> Hi!
> 
> I tried latest binutils and also included the patch H . J . Lu posted 
> tonight. But I still have a problem with the build of linux-kernel (2.4.10)
> 
> The documentation for this ld error I honestly don't understand, it talks 
> about that the ldscript shouldn't use SIZEOF_HEADERS, but I didn't 
> change anything in that. I updated binutils from 2.11.90.0.31 and there
> it worked, so I'm not sure if this a bug or if I misconfigured binutils.
> 
> Greetings, Stephan
> 
> gcc -D__ASSEMBLY__ -D__KERNEL__-I/usr/src/linux/include  -traditional -c 
> head.S
> gcc -D__KERNEL__ -I/usr/src/linux/include  -Wall -Wstrict-prototypes 
> -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer 
> -pipe -mpreferred-stack-boundary=2 -march=i686 -Os -c misc.c
> ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
> ld: bvmlinux: Not enough room for program headers (allocated 2, need 3)
> ld: final link failed: Bad value

Works fine with binutils 2.11.92.0.7, which I relased today.


H.J.

Re: Not enough room for program headers (problem with 2.11.92.0.5)

[H . J . Lu]

On Wed, Oct 17, 2001 at 11:43:24AM +0200, Stephan Kulow wrote:
> On Wednesday 17 October 2001 08:50, H . J . Lu wrote:
> 
> > Works fine with binutils 2.11.92.0.7, which I relased today.
> >
> 
> I figured meanwhile what's the problem. The default for combreloc is changed 
> in my version of binutils, so the test case would be this. The problem is the 

Don't do that :-).

> combination of -z combreloc and -Ttext. If you leave out one of them, it 
> works. 
> I think it's my fault, but I want to report it nonetheless, maybe it's still 
> a bug behind the scenes :)
> 
> Greetings, Stephan
> 
> # ld -v
> GNU ld version 2.11.92.0.7 20011016
> # gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> # gcc -c misc.i
> # ld -z combreloc -m elf_i386 -Ttext 0x100000 misc.o
> ld: a.out: Not enough room for program headers (allocated 2, need 3)
> ld: final link failed: Bad value
> 

Don't use -z combreloc in this case. That is one reason why I didn't
turn on -z combreloc by default in my binutils. It should only be done
when it makes senses and is safe. It looks like no one should turn on
-z combreloc by default unless everything is worked out.


H.J.

Re: Not enough room for program headers (problem with 2.11.92.0.5)

[H . J . Lu]

On Wed, Oct 17, 2001 at 06:11:08PM +0200, Jakub Jelinek wrote:
> > 
> > Don't use -z combreloc in this case. That is one reason why I didn't
> > turn on -z combreloc by default in my binutils. It should only be done
> > when it makes senses and is safe. It looks like no one should turn on
> > -z combreloc by default unless everything is worked out.
> 
> Can I get a copy of misc.o (or misc.i)?
> -z combreloc really should be the default, the speed advantages are huge, so
> if there is some issue with it, I'd like to debug it.
> 

See misc.i in

http://sources.redhat.com/ml/bug-gnu-utils/2001-10/msg00194.html


H.J.

[PATCH] Fix -Ttext -z combreloc (was Re: Not enough room for program headers (problem with 2.11.92.0.5))

[Jakub Jelinek]

Hi!

On Wed, Oct 17, 2001 at 09:16:36AM -0700, H . J . Lu wrote:
> On Wed, Oct 17, 2001 at 06:11:08PM +0200, Jakub Jelinek wrote:
> > > Don't use -z combreloc in this case. That is one reason why I didn't
> > > turn on -z combreloc by default in my binutils. It should only be done
> > > when it makes senses and is safe. It looks like no one should turn on
> > > -z combreloc by default unless everything is worked out.
> > 
> > Can I get a copy of misc.o (or misc.i)?
> > -z combreloc really should be the default, the speed advantages are huge, so
> > if there is some issue with it, I'd like to debug it.
> > 
> 
> See misc.i in
> 
> http://sources.redhat.com/ml/bug-gnu-utils/2001-10/msg00194.html

What happens is that _bfd_strip_section_from_output was not ever stripping
output .rel.dyn section, because 2 different sections in dynobj had it as
their output_section (.rel.text and .rel.data). As
_bfd_strip_section_from_output doesn't change the input sections in any way,
when calling it on .rel.text it wasn't stripped because .rel.data pointed to
it too (that's correct), but when calling it on .rel.data, it wasn't
stripped because .rel.text pointed to it too (but .rel.text shouldn't count
as reference since _bfd_strip_section_from_output was called on it already).
Here are 2 alternative patches, the first one uses SEC_EXCLUDE flag to mark
input section's whose output was stripped, the second one makes a copy of
the output section. Setting s->output_section to bfd_abs_section_ptr doesn't
work, it is too late.
Ok to commit the first one (provided you think I can abuse SEC_EXCLUDE flag
for this - make check passed)?

	Jakub

Re: [PATCH] Fix -Ttext -z combreloc (was Re: Not enough room for program headers (problem with 2.11.92.0.5))

[Alan Modra]

On Wed, Oct 17, 2001 at 08:15:24PM +0200, Jakub Jelinek wrote:
> 
> 	* section.c (_bfd_strip_section_from_output): Don't count
> 	SEC_EXCLUDE sections as references.  Set SEC_EXCLUDE.

Seems reasonable to me.

Re: Not enough room for program headers (problem with 2.11.92.0.5)

[Jakub Jelinek]

On Wed, Oct 17, 2001 at 08:24:21AM -0700, H . J . Lu wrote:
> > I figured meanwhile what's the problem. The default for combreloc is changed 
> > in my version of binutils, so the test case would be this. The problem is the 
> 
> Don't do that :-).
> 
> > combination of -z combreloc and -Ttext. If you leave out one of them, it 
> > works. 
> > I think it's my fault, but I want to report it nonetheless, maybe it's still 
> > a bug behind the scenes :)
> > 
> > Greetings, Stephan
> > 
> > # ld -v
> > GNU ld version 2.11.92.0.7 20011016
> > # gcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
> > gcc version 2.95.2 19991024 (release)
> > # gcc -c misc.i
> > # ld -z combreloc -m elf_i386 -Ttext 0x100000 misc.o
> > ld: a.out: Not enough room for program headers (allocated 2, need 3)
> > ld: final link failed: Bad value
> > 
> 
> Don't use -z combreloc in this case. That is one reason why I didn't
> turn on -z combreloc by default in my binutils. It should only be done
> when it makes senses and is safe. It looks like no one should turn on
> -z combreloc by default unless everything is worked out.

Can I get a copy of misc.o (or misc.i)?
-z combreloc really should be the default, the speed advantages are huge, so
if there is some issue with it, I'd like to debug it.

	Jakub

Re: Not enough room for program headers (problem with 2.11.92.0.5)

[Jakub Jelinek]

On Wed, Oct 17, 2001 at 09:16:36AM -0700, H . J . Lu wrote:
> On Wed, Oct 17, 2001 at 06:11:08PM +0200, Jakub Jelinek wrote:
> > > 
> > > Don't use -z combreloc in this case. That is one reason why I didn't
> > > turn on -z combreloc by default in my binutils. It should only be done
> > > when it makes senses and is safe. It looks like no one should turn on
> > > -z combreloc by default unless everything is worked out.
> > 
> > Can I get a copy of misc.o (or misc.i)?
> > -z combreloc really should be the default, the speed advantages are huge, so
> > if there is some issue with it, I'd like to debug it.
> > 
> 
> See misc.i in
> 
> http://sources.redhat.com/ml/bug-gnu-utils/2001-10/msg00194.html

This is because for some reason empty .rel.dyn section was not stripped away
(debugging now) from output_bfd and as that comes before .text, it wanted to
have 0x08048XXX address.

	Jakub