Hi Mark,

  This is actually expected behaviour for the annobin plugin.  It has to bias the symbol positions because if it did not they would coincide with the start of functions.  (Well for sections that actually contain code that is).  This is a bad thing, because the PPC linker creates special entry symbols for functions which are needed by the ABI.  But it only does this if there are no symbols already at the function entry point.  (It assumes that if a symbol is there, then it has been created by hand crafted assembler code, and so it does not need synthesise its own).  Basically if the +4 bias was not used, PPC linking would break in the presence of annobin symbols.

  As far as I know there is no requirement that a section relative symbol actually lie inside its section.  So the symbols are legal, if unconventional.

  Could eu-elflint ignore these symbols ?

Cheers
  Nick

(In reply to Nick Clifton from comment #1)
>   This is actually expected behaviour for the annobin plugin.  It has to
> bias the symbol positions because if it did not they would coincide with the
> start of functions.  (Well for sections that actually contain code that is).
> This is a bad thing, because the PPC linker creates special entry symbols
> for functions which are needed by the ABI.  But it only does this if there
> are no symbols already at the function entry point.  (It assumes that if a
> symbol is there, then it has been created by hand crafted assembler code,
> and so it does not need synthesise its own).  Basically if the +4 bias was
> not used, PPC linking would break in the presence of annobin symbols.

OK, but there is no code (or function) there, so why add the symbol in the first place?

>   As far as I know there is no requirement that a section relative symbol
> actually lie inside its section.  So the symbols are legal, if
> unconventional.

The spec says: "In relocatable files, st_value holds a section offset for a defined symbol. st_value is an offset from the beginning of the section that st_shndx identifies." I don't think an offset outside the section is valid, what would that even mean?

>   Could eu-elflint ignore these symbols ?

It is not clear to me how to identify them (except by matching on name, but that would be really messy). How are they different from normal symbols in an ET_REL file that do have invalid section offset st_values?

(In reply to Mark Wielaard from comment #2)
Hi Mark,

> OK, but there is no code (or function) there, so why add the symbol in the
> first place?

Because at the time that the symbols are created, the plugin does not know
if there will be any code in the section.


> >   As far as I know there is no requirement that a section relative symbol
> > actually lie inside its section.  So the symbols are legal, if
> > unconventional.
> 
> The spec says: "In relocatable files, st_value holds a section offset for a
> defined symbol. st_value is an offset from the beginning of the section that
> st_shndx identifies." I don't think an offset outside the section is valid,
> what would that even mean?

I don't see why it would not be valid.  It is just an offset.  The standard does
not mandate any semantics for symbol offsets.  It is up to the consumer to decide
what interpretation to put on the symbol's offset.  

In the case of the annobin symbols that are causing the problems, the offset 
means "the place where section FOO begins plus four".


> >   Could eu-elflint ignore these symbols ?
> 
> It is not clear to me how to identify them (except by matching on name, but
> that would be really messy). How are they different from normal symbols in
> an ET_REL file that do have invalid section offset st_values?

The symbols are a little special.  They are HIDDEN, LOCAL and have NOTYPE.
They do also contain the "annobin" string, but I agree that checking for this
would be a little bit hackish.

I will try some experiments with the plugin and see if I can detect empty
sections or change the offset of the start symbols to be no more than the 
offset of the end symbols.

Cheers
  Nick

Ha!  It turns out that there already was some code in the annobin plugin that was supposed to fix this problem, but it broke when I changed the PowerPC symbol bias from 2 to 4.  I am testing a local fix now...

Right - this should now be fixed in annobin-9.33-1.fc34.

Thanks, confirmed by a new elfutils-0.181-2.fc34 ppc64le build.

Sadly, this bug has returned:

https://koji.fedoraproject.org/koji/taskinfo?taskID=57523377

(In reply to Jeff Law from comment #7)
> Sadly, this bug has returned:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=57523377

*sigh* Yes - but I am not sure what to do about it this time.

The cause is that annobin needs to create start and end symbols for any given code 
section.  But for the hot and cold text sections gcc can create multiple instances 
of the same section, so there is no way to ensure that annobin's end symbol will be 
placed after all the others.  Instead annobin places the end symbol into sections 
called .text.hot.zzz or .text.cold.zzz and it relies upon the linker's alphabetic 
sorting of sections to make sure that the symbol is at the end.

For the PowerPC however there is an additional problem - the start symbol cannot appear
at the start of the code section.  This is because the ppc linker creates special 
ABI-mandated entry symbols for functions, but only if there are no symbols present 
already present at the function's start address.  (Crazy but true).  So - in order to
work around this, annobin adds 4 to the address of any (powerpc) start symbol that it 
creates.

Which is fine, except for empty PowerPC sections.  Because now they have a start symbol
that is placed beyond the end of the section.  Annobin used to fix this by adding extra
code into the generated assembler that effectively performs: "if start > end then start = end"
But - this only works if the start and end symbol are in the same section.  If they are
in different sections then the assembler cannot evaluate the expression and so it errors
out.  Hence the fix works for some sections, but not the hot and cold sections.

Again this used to work because gcc would not generate hot and cold text sections for
the powerpc.  But as of gcc 10 and LTO compilation it does.  And so we are back to where
this BZ came in.

Now I still maintain that there is nothing intrinsicly wrong with a section relative
symbol having an address that it outside of the section.  There can be perfectly
legitimate reasons for doing this.  But the elfutils do not like them and annobin wants
to play nice, so I need to think up another solution.  Maybe I could force empty 
sections to be non-empty ?

Any-who I am on PTO now, so I will look at this once I get back.

So it seems this really is a linker problem on ppc64le. There must be a way to create normal symbols at a function start.

Having symbols with offsets beyond the section they are associated with is a problem in general since it is unclear how to handle them when merging sections, where should that symbol point to? It seems wrong to just make it point at some arbitrary data added.

If the issue is multiple .text sections with the same name, and you already create a new section with a name lexically at the end to place the end symbol in, can't you then not also create an (empty) start section with a name lexically before the others to place the start symbol in? Then you don't need any extra offset.

*** Bug 1908863 has been marked as a duplicate of this bug. ***

Hi Mark,

  Do you have a small testcase that will reproduce this problem ?

  I know that I could try rebuilding all of elfutils and running its testsuite, but I am looking for just a small program that I can compile on its own, but which still triggers errors from eu-elflint.

Cheers
  Nick

Not having access to a rawhide ppc64le setup right now I cannot easily try to reduce something.

But the src/size.c program in elfutils shows the issue and is fairly small itself.
$ wc src/size.c 
  667  2499 17557 src/size.c

I still haven't replicated, but if you just want to build size.c then the following patch should help:

diff --git a/src/size.c b/src/size.c
index e49b64b8..3506f1ff 100644
--- a/src/size.c
+++ b/src/size.c
@@ -16,9 +16,14 @@
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
-#ifdef HAVE_CONFIG_H
-# include <config.h>
-#endif
+#include "eu-config.h"
+
+#define HAVE_DECL_POWEROF2 1
+#define PACKAGE_BUGREPORT "foobar" 
+#define PACKAGE_TARNAME "foobar"
+#define LOCALEDIR "foobar"
+#define PACKAGE_VERSION 0
+#define fputs_unlocked fputs
 
 #include <argp.h>
 #include <fcntl.h>

Then build with something like:

gcc -I ../lib -fstack-clash-protection -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -g -O2 -c size.c

But I'll try to get hold of a ppc64le machine where this fails to make sure.

OK I have created a new annobin (annobin-9.57-1.fc34) which should solve this problem.

Note - the new annobin needs to be in the buildroot as I have updated the gcc plugin.

Local testing confirms that the elfutils source rpm can be built on a ppc64le machine, so I am hoping that this time everyone will be happy.

Confirmed. elfutils-0.182-2.fc34 build fine with annobin-9.57-1.fc34 installed, including a full green testsuite.
https://koji.fedoraproject.org/koji/taskinfo?taskID=59709103