[Bug gold/18935] Gold assert fail when moving dot in NOLOAD section.

[johan.karlsson at enea dot com]

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

--- Comment #3 from Johan Karlsson  ---
(In reply to Cary Coutant from comment #2)
> > Seems a bit unclear what the expected behavior is.
> >
> >  .init_stack (NOLOAD) :
> >  {
> >. = . + 0x200;
> >  } :ph_load
> > With this ld.bfd creates a NOBITS SHF_ALLOC section(just like .bss).
> >
> > When a new non-SHF_ALLOC output section is created the address is set to 0.
> > Layout::make_output_section_for_script(), which is the function that creates
> > the init_stack section, only tries to create sections with SHT_PROGBITS
> > section. This is why the assert fails when
> > Output_section_definition::set_section_addresses() tries to assign an 
> > address
> > to the section.
> 
> This script looks like it's trying to create an unloadable section,
> then allocate it to a loadable segment. If all the script is trying to
> do is create a loadable NOBITS section, the NOLOAD attribute shouldn't
> be necessary (or allowed). The fact that it contains nothing but
> uninitialized space should be sufficient. I don't think gold does the
> right thing in that case, but that ought to be the bug, not that
> NOLOAD should make it work.
> 
> What does Gnu ld do if you omit NOLOAD? Do you have any history that
> explains why NOLOAD was added to the script?
> 
> -cary

When removing NOLOAD Gnu ld still makes it a NOBITS section, guess it
recognizes that it is empty and does that. Because if I just add an int to that
section it will create it as PROGBITS. And if I then add the NOLOAD again it is
back to NOBITS.

The linker scripts are for embedded systems that usually load binaries. So if
we put things in NOLOAD section the binaries are smaller.

This PR is highly tied to the discussion in the mailing list. Seems like NOLOAD
is implemented in gold just as described by the linker documentation. 
However Gnu ld does not do that for ELF, see ld/ldlang.c

  /* Unfortunately GNU ld has managed to evolve two different
 meanings to NOLOAD in scripts.  ELF gets a .bss style noload,
 alloc, no contents section.  All others get a noload, noalloc
 section.  */

I think the best is to change the behavior of gold to be compatible with Gnu
ld.

/Johan

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss

[stsp at users dot sourceforge.net]

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

--- Comment #15 from Stas Sergeev  ---
(In reply to Cary Coutant from comment #14)
> I don't see why we should leave this bug unfixed just because we don't match
> Gnu ld's behavior for -Ttext.
> 
> The original report was about accepting hex numbers without the 0x, and had
> nothing to do with what you're talking about.
Ah, if your patch can fix the problem for other
people here, then fine. My expectation is that it
just won't. It doesn't fix anything for me for sure.

Can someone in this thread confirm such a change
can fix anything at all, even despite the other
incompatibilities of the same -Ttext option?

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/18855] String constants mixed up when linked with gold on Linux/sparc64

[glaubitz at physik dot fu-berlin.de]

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

glaubitz at physik dot fu-berlin.de  
changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/18855] String constants mixed up when linked with gold on Linux/sparc64

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from glaubitz at physik dot fu-berlin.de  ---
Hi Cary!

(In reply to Cary Coutant from comment #1)
> Sorry, I don't have a SPARC development environment, so to investigate this,
> I'm going to need all the .o files (real .o files, not LTO intermediates).

I can actually provide one for you. I'll contact you shortly.

> Does it still fail without -flto?
> 
> Can you add -Wl,--stats to the command line and attach the output?

I can also provide any additional debug information you need. This bug seems to
seriously hamper Debian's sparc64 port, so I am more than happy to help!

Adrian

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/18963] New: Addition is not commutative

[felix.von.s at posteo dot de]

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

Bug ID: 18963
   Summary: Addition is not commutative
   Product: binutils
   Version: 2.25
   URL: http://www.zytor.com/pub/git/dos/virtio9p.git/
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: felix.von.s at posteo dot de
  Target Milestone: ---

Created attachment 8610
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8610&action=edit
Failing linker script

I've recently stumbled upon 
and decided to try it. I cloned the repository, ran "make", started the
executable in qemu, and it promptly crashed.

I looked into the map file and noticed that the entry point address in the
header is wrong. After about half an hour, I found a fix:

+++ dostsr.ld
-   __init_lma = __dgroup_lma + __rbss_start - __init_vma;
+   __init_lma = __dgroup_lma - __init_vma + __rbss_start;
[...]
-   _exe_start = _start + __rbss_start - __init_vma;
+   _exe_start = _start - __init_vma + __rbss_start;
[...]
-   _edata_premove = _edata + __rbss_start - __init_vma;
+   _edata_premove = _edata - __init_vma + __rbss_start;

For some reason, wherever the linker script contained definition of the form A
= B + C - D, ld silently took it to mean A = B + C + D. Changing the order of
summation fixed the problem.

It doesn't always happen, though: when I tried to create a minimal test case,
sometimes the link succeeded, sometimes it didn't. The result seems to depend
on whether there is overflow in the computation. The attached script fails to
link; however, if I instead set D = A - B + C and E = A + C - B, it links
successfully.

gold refused to link the original executable altogether, since it has
overlapping sections (for good reasons, though). The attached script is linked
without surprises.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss

[stsp at users dot sourceforge.net]

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

--- Comment #16 from Stas Sergeev  ---
(In reply to Cary Coutant from comment #14)
> The original report was about accepting hex numbers without the 0x, and had
> nothing to do with what you're talking about.
Note that the original report was explicitly about -Ttext.
Your change will likely remove the mentioned error
message, but people will start wondering why it still
doesn't work. So you can turn an explicit error msg into
a silent breakage.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10774] Bogus documentation

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Konrad,

  Sorry for letting this PR languish for so long.

  I agree that the wording of the Source Code Reference section is wrong, but I
think that your proposed replacement is a little bit too terse.  I particularly
want to include the memcpy examples as it was precisely this piece of code that
tripped up a customer and caused them to file a bogus bug report.  Thus please
could you tell me if you are happy with the following replacement version
instead:

Cheers
  Nick

3.5.5 Source Code Reference
---

The value of a symbol is its address.  Thus to access a symbol's value
from a high level language it should be declared as an external variable
and its address used.

   Note that in most cases, symbols defined by linker scripts do _not_
have any associated storage assigned to them, so it is typically an
error to read from or write to such an external variable.  For example,
suppose that a linker script defines some symbols like this:

   start_of_ROM   = .ROM;
   end_of_ROM = .ROM + sizeof (.ROM);
   start_of_FLASH = .FLASH;

   The the following code to copy data from ROM to FLASH will fail:

   extern char start_of_ROM, end_of_ROM, start_of_FLASH;
   memcpy (start_of_FLASH, start_of_ROM, end_of_ROM - start_of_ROM); /*
FAIL */

   This is because it is reading from the symbols.  Instead the copy
should be written as:

   extern char start_of_ROM, end_of_ROM, start_of_FLASH;
   memcpy (& start_of_FLASH, & start_of_ROM, & end_of_ROM - &
start_of_ROM);

   Note the use of the '&' operators - these are correct.  Or the copy
could be written as:

   extern char start_of_ROM[], end_of_ROM[], start_of_FLASH[];
   memcpy (start_of_FLASH, start_of_ROM, end_of_ROM - start_of_ROM);

   Which is easier to read and enables the C compiler to diagnose
writes, reads (without array dereference) and use of the sizeof operator
as errors.

   Type checking is not performed on linker symbols, so any type can be
used to reference them.  Note however that using the wrong type could
lead to runtime problems.  For example:

   extern int start_of_FLASH[];
   * start_of_FLASH = 1;

   This could result in a runtime failure if the start_of_FLASH symbol
is not assigned to an address that meets the alignment requirements of
the int data type.

   Finally, note that some systems perform a transformation between
variable names as used in a high-level language and symbol names as seen
by the linker.  The transformation can be an artefact of the high level
language - for example name mangling in C++, or it can be part of the
architecture's ABI - for example prepending an underscore to variable
names.  If a linker script symbol is to be accessed from a high level
language then this transformation must be taken into account.  For
example in C a linker script symbol might be referred to as:

   extern int foo[];

   But in the linker script it might need to be defined as:

   _foo = 1000;

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/18968] New: make check fails on arm embedded NAS with no neon fpy

[c.e.macfarlane at macfh dot co.uk]

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

Bug ID: 18968
   Summary: make check fails on arm embedded NAS with no neon fpy
   Product: binutils
   Version: 2.25
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: c.e.macfarlane at macfh dot co.uk
  Target Milestone: ---

Hi, trying to build binutils on an embedded arm device, a Zyxel NSA221.  After
some trial and error, I've now got a configuration that builds ...

export CFLAGS='-I/opt/include -I/opt/share/include'; export LDFLAGS='-L/opt/lib
-L/opt/share/lib -L/opt/arm-none-linux-gnueabi/lib'; ./configure --prefix=/opt
--with-newlib --with-gmp=/opt/share/ --with-mpfr=/opt/share/
--with-mpc=/opt/share/

... but after an apparently successful make (no -k switch), when I come to
testing, there are errors.  I can't decide whether the errors are being caused
by the absence of a neon fpu, or something more obscure and/or important.

Can someone advise as to whether I can proceed to make install or that this
serious enough to halt installation until fixed?

~/build/binutils-2.25.1 # make -k check
make[1]: Entering directory `/root/build/binutils-2.25.1'
make[2]: Entering directory `/root/build/binutils-2.25.1/bfd'
make  check-recursive
make[3]: Entering directory `/root/build/binutils-2.25.1/bfd'
Making check in doc
make[4]: Entering directory `/root/build/binutils-2.25.1/bfd/doc'
make[4]: Nothing to be done for `check'.
make[4]: Leaving directory `/root/build/binutils-2.25.1/bfd/doc'
Making check in po
make[4]: Entering directory `/root/build/binutils-2.25.1/bfd/po'
make[4]: Nothing to be done for `check'.
make[4]: Leaving directory `/root/build/binutils-2.25.1/bfd/po'
make[4]: Entering directory `/root/build/binutils-2.25.1/bfd'
make[4]: Leaving directory `/root/build/binutils-2.25.1/bfd'
make[3]: Leaving directory `/root/build/binutils-2.25.1/bfd'
make[2]: Leaving directory `/root/build/binutils-2.25.1/bfd'
make[2]: Entering directory `/root/build/binutils-2.25.1/opcodes'
Making check in .
make[3]: Entering directory `/root/build/binutils-2.25.1/opcodes'
make[3]: Leaving directory `/root/build/binutils-2.25.1/opcodes'
Making check in po
make[3]: Entering directory `/root/build/binutils-2.25.1/opcodes/po'
make[3]: Nothing to be done for `check'.
make[3]: Leaving directory `/root/build/binutils-2.25.1/opcodes/po'
make[2]: Leaving directory `/root/build/binutils-2.25.1/opcodes'
make[2]: Entering directory `/root/build/binutils-2.25.1/binutils'
make  check-recursive
make[3]: Entering directory `/root/build/binutils-2.25.1/binutils'
Making check in doc
make[4]: Entering directory `/root/build/binutils-2.25.1/binutils/doc'
make[4]: Nothing to be done for `check'.
make[4]: Leaving directory `/root/build/binutils-2.25.1/binutils/doc'
Making check in po
make[4]: Entering directory `/root/build/binutils-2.25.1/binutils/po'
make[4]: Nothing to be done for `check'.
make[4]: Leaving directory `/root/build/binutils-2.25.1/binutils/po'
make[4]: Entering directory `/root/build/binutils-2.25.1/binutils'
make  check-DEJAGNU
make[5]: Entering directory `/root/build/binutils-2.25.1/binutils'
srcdir=`cd . && pwd`; export srcdir; \
r=`pwd`; export r; \
LC_ALL=C; export LC_ALL; \
EXPECT=expect; export EXPECT; \
runtest=runtest; \
if /opt/bin/bash -c "$runtest --version" > /dev/null 2>&1; then \
  CC_FOR_TARGET="gcc" CFLAGS_FOR_TARGET="-I/opt/include -I/opt/share/include" \
$runtest --tool binutils --srcdir ${srcdir}/testsuite \
; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi
WARNING: could not find `runtest'
make[5]: Leaving directory `/root/build/binutils-2.25.1/binutils'
make[4]: Leaving directory `/root/build/binutils-2.25.1/binutils'
make[3]: Leaving directory `/root/build/binutils-2.25.1/binutils'
make[2]: Leaving directory `/root/build/binutils-2.25.1/binutils'
make[2]: Entering directory `/root/build/binutils-2.25.1/etc'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/root/build/binutils-2.25.1/etc'
make[2]: Entering directory `/root/build/binutils-2.25.1/gas'
Making check in doc
make[3]: Entering directory `/root/build/binutils-2.25.1/gas/doc'
make[3]: Nothing to be done for `check'.
make[3]: Leaving directory `/root/build/binutils-2.25.1/gas/doc'
Making check in po
make[3]: Entering directory `/root/build/binutils-2.25.1/gas/po'
make[3]: Nothing to be done for `check'.
make[3]: Leaving directory `/root/build/binutils-2.25.1/gas/po'
make[3]: Entering directory `/root/build/binutils-2.25.1/gas'
make  check-DEJAGNU
make[4]: Entering directory `/root/build/binutils-2.25.1/gas'
if [ -d testsuite ]; then \
  true; \
else \
  mkdir testsuite; \
fi
rm -f testsuite/site.exp
cp site.exp testsuite/site.exp
rootme=`pwd`; export rootme; \
srcdir=`cd .; pwd` ; export srcdir ; \
LC_ALL=C; export LC_ALL; \
EXPECT=expect ; export EXPECT ; \
runtest=runtest; \

[Bug binutils/18968] make check fails on arm embedded NAS with no neon fpu

[c.e.macfarlane at macfh dot co.uk]

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

C E Macfarlane  changed:

   What|Removed |Added

Summary|make check fails on arm |make check fails on arm
   |embedded NAS with no neon   |embedded NAS with no neon
   |fpy |fpu

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10774] Bogus documentation

[konrad.schwarz at siemens dot com]

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

--- Comment #2 from Konrad Schwarz  ---
I believe ELF reserves section names beginning with a dot for its own use, so
technically you shouldn't name your sections .FLASH or .ROM.

The compiler will issue a diagnostic for a write to a const-qualified object.
In your example, the symbols are not const qualified.  You would make more use
of the type-checking facilities of the compiler with

extern char const start_of_FLASH [];

This makes the clause about the compiler being able to check writes true.

(You would then probably want to replace start_of_FLASH with start_of_ROM in
the later example dealing with alignment.)

I prefer `&start_of_FLASH' to `& start_of_FLASH'; as I leave a space around
binary operators `a & b', it makes it easier to distinguish between the unary
and binary meanings of `&'.

In the final section, I would write "transformations".  There is one
transformation from C++ symbol to C symbol names (mangling), and possibly a
second transformation from C to assember/linker names (e.g., underscore
prepending).  Mangling is dealt with `extern "C"'.  You could add that from
C++, you need to declare `foo' as `extern "C" int foo [];'

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils