[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning

[matz at suse dot de]

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

--- Comment #4 from Michael Matz <matz at suse dot de> ---
(In reply to Nick Clifton from comment #3)
> (In reply to Michael Matz from comment #2)
> > Hmm, on reflection this proposed message might not actually be correct.
> > Generally one can't just increase the alignment of random data symbols like
> > here: they might be part of a larger object with known relative offsets, and
> > changing the alignment of such data symbol will then break such knowledge.
> 
> Can this happen ?
> 
> More to the point, if a meta-object does contain sub-objects with their own
> symbols, shouldn't the offsets of those sub-objects be computed by
> calculating
> the difference between the symbol's address and the meta-object's start
> address.  Rather than just by being pre-calculated to some fixed value ?

Sometimes yes.  But the more usual case is that the addresses are encoded as
section-relative.  Especially so if the symbols in question aren't global, but
still just so happen to be related (by positioning) to the common symbol that
is
tried to be moved around.  For instance, in this example:

% cat test1.s
  .type   com2_,@object
  .comm   com2_,8,64
  .quad   com2_
  .type   com1_,@object
  .comm   com1_,8,64
  .quad   com1_
.section .note.GNU-stack

% cat test2.s
  .globl  com2_
  .data
randomstuff:
   .quad  1
  .align 32
  .type   com1_, @object
  .size   com1_, 8
com1_:
  .quad   2
  .align 32
  .type   com2_, @object
  .size   com2_, 8
com2_:
  .quad   2
foobar:
  .quad   3
addroffoobar:
   .quad  foobar - randomstuff
.section .note.GNU-stack

main.c and compile commands as above.  Note how I now have two "problematic"
common symbols, both constrained to be 64-aligned from test1.s, but actually
only getting a 32-alignment in test2.s.  Not also that the distance between
com1_ and com2_ is basically fixated in test2.s because I encode a distance
between sourrounding (non-global) symbols.  So, as a whole this .data section
from test2.s can move happily around, but of course nothing can be added
right _into_ that blob representing test2.o:.data.  To wit:

% cc ...
ld: warning: alignment 32 of symbol `com2_' in test2.o is smaller than 64 in
test1.o

Note how it complains only about one, not both, symbols.  And further:

% readelf -sW a.out
...
    15: 0000000000404020     0 NOTYPE  LOCAL  DEFAULT   23 randomstuff
...
    17: 0000000000404068     0 NOTYPE  LOCAL  DEFAULT   23 foobar
    18: 0000000000404070     0 NOTYPE  LOCAL  DEFAULT   23 addroffoobar
...
    28: 0000000000404060     8 OBJECT  GLOBAL DEFAULT   23 com2_
...
    43: 00000000004040c0     8 OBJECT  GLOBAL DEFAULT   25 com1_

% readelf -x .data a.out
Hex dump of section '.data':
  0x00404000 00000000 00000000 00000000 00000000 ................
  0x00404010 00000000 00000000 00000000 00000000 ................
  0x00404020 01000000 00000000 00000000 00000000 ................
  0x00404030 00000000 00000000 00000000 00000000 ................
  0x00404040 02000000 00000000 00000000 00000000 ................
  0x00404050 00000000 00000000 00000000 00000000 ................
  0x00404060 02000000 00000000 03000000 00000000 ................
  0x00404070 48000000 00000000                   H.......

So, it correctly left the distance between foobar and randomstuff at 0x48,
both in symbol table and .data content.  It achieved the 64-alignment of
'com1_'
by letting the begin of test2.o:.data (corresponding also to the symbol
'randomstuff') be at 0x20 within a.out:.data.  But that means that com2_ also
had to move with it, to .data+0x60.  That's _not_ 64-aligned.  And especially
it can't be made 64-aligned in any way.  Either it would break the
alignment of com1_ again, or it would change the distance between randomstuff
and foobar, which wouldn't be able to rectified as no trace of that is left
in the object files (and rightly so!).

Curiously it only gave a warning message about com2_, which is the one where
it couldn't do any alignment upgrade, but not about com1_ where it actually did
change it.

So, all in all, ultimately I think:
a) the suggested wording of the warning is wrong, as not achievable in the
   general case
b) the above example shows how the warning might even be regarded as error.
   Code that assumes 64-alignment for com1_ and com2_ (as requested by test1.o)
   _will_ break with the generated output and there's no way for the linker
   to magically make it work.

In the interest of backward compatibility and in light of the existence of
-fcommon for C, even though its default changed a couple years back, which
makes mixture of common and data symbols be somewhat common, I'm not actually
suggesting to make this an error, though.

We could give the suggested wording of the warning in the very specific case
where the target alignment is achievable.  But the current code doesn't lend
itself to that, at the place the warning is given it doesn't really know
yet if that symbol can be over-aligned or not.  (As shown above by the fact
that
it warns about the wrong and not about the right symbol).

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