Ronald G Minnich <[EMAIL PROTECTED]> writes:

> I have been seeing lots of problems with gnu ld and the ldscripts. It just
> doesn't handle muliple sections well at all. The latest problem is antonio
> catani's.


> you get the following error:
> gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> linuxbios.o
> /usr/bin/ld: section .data [00086b50 -> 0008812f] overlaps section
> .rodata.str1.1 [00086b50 -> 000873dc]

Youch.  Very not good.
 
> Note what it did: it treated the .rodata as zero-sized, and put the .data
> right on top of it, then complained. This is better than what it used to
> do on Alpha, where it would place the stack right in the middle of heap,
> and get errors that were hard if not impossible to figure out (the symptom
> would be that in the middle of gunzip you would get very strange errors
> with weird return addresses -- since the data from gunzip overwrote the
> stack).
> 
> The fix is to get rid of those sections, viz:
>        .text (.) : {
>                 _text = .;
>                 *(.text);
>                 *(.text.*);
>                 _etext = .;
>                 _rodata = .;
>                 *(.rodata)
>                 _erodata = .;
>                 _data = .;
>                 *(.data)
>                 _edata = .;
>         }
> 
> Builds with no errors, and places all the pieces correctly.

Except the virtual addresses of variables in the data
section are wrong and the code won't run.


> ld would just make a total mess of things otherwise.
> 
> I think we need to simplify these scripts, these bugs in ld have been
> plaguing me across several versions of the GNU ld/bfd utilities. For
> purposes of linuxbios it does not matter than much that we have the
> correctly named sections. How about we go to just the .text and .data
> areas and do things by symbol, not section? what is the best way out of
> this mess.

Good question.  Can we get a list of problematic versions.  If it is
something as simple as the new version works but the version doesn't
checking the version number and giving up is my preferred solution.

With ld 2.10.90  I don't have any problems ld --version.

What we may be able to do to simplify the life of ld is set it up so
we don't play the virtual/physical address games.

It seriously looks like simply having new enough tools might be
the solution.  Every time I have tracked it that was the problem/difference.

If so we need something like the linux Documetation/Changes that lists
the version of the utilities you need to build linuxBIOS.

Eric


Reply via email to