Well, there is a \001/^A byte in the note name, so there isn't much that eu-readelf can do here.  eu-readelf shouldn't produce U+00FF characters in the output, though.

I don't think this is a error in eu-readelf, it just produces the NOTE name. annobin really shouldn't use unprintable characters in the NOTE string name. The NOTE name is null-terminated character representation of the entry's owner. It should be something like "GNU" or "annobin". But it appears to encode data, which should go into the note descriptor.

BTW. For the ruby testcase it would probably help to just grep for the stapsdt probe NOTEs. Just only scan for the 2 lines after a stapsdt owner NOTE with:

probes_detected = `eu-readelf -n "#{LIBRUBY_SO}" | grep -A2 "^  stapsdt"`

I don't understand why this exhibits itself on F28 and not on Rawhide while elfutils are of the same version on Rawhide as well as F28:

$ rpm -qf `which eu-readelf`
elfutils-0.170-1.fc27.x86_64

(In reply to Mark Wielaard from comment #3)
I think I am going to give you some time to fix this prior applying the workaround ;)

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

> I don't think this is a error in eu-readelf, it just produces the NOTE name.
> annobin really shouldn't use unprintable characters in the NOTE string name.
> The NOTE name is null-terminated character representation of the entry's
> owner. It should be something like "GNU" or "annobin". But it appears to
> encode data, which should go into the note descriptor.

This was an unfortunately design choice, but it is too late to change it now without loosing backwards compatibility.

Interestingly, there appears to be something wrong with the note that is being displayed by eu-readelf:

  GA*ÿÿÿÿÿÿÿÿ 

Assuming that the first \001 byte is correct, then this is supposed to be a version note which includes a printable string as the rest of its name, rather
than a numeric sequence.  Ie it is supposed to be:

  GA$\0013p5\000

(Which indicates version 3 of the protocol and version 5 of the plugin).

I think that the note that eu-readelf is displaying has been corrupted somehow,
and this is what is causing the display problems.  I am not sure what would be causing this corruption however.

Cheers
  Nick

Hi Vít,

> Ruby recently started to fail on F28 since this Koschei build 

Which version of the annobin package are you using ?


> [ The build fails at this
> line [2], where the "eu-readelf" output is processed.

Would it be possible for you to upload the binary file that is being
processed at this point ?

Also - do you get similar problems if you use the readelf program from
the binutils package instead of eu-readelf ?


> Not sure if this is really annobin but this is my best guess.

It probably is annobin's fault, somehow, but in order to find out what
is causing it, it would be really helpful to have a small, reproducible
test case.  Is there any change that you could capture the compilation 
that is producing the binary that contains the bogus annobin note ?

Cheers
  Nick

(In reply to Nick Clifton from comment #7)
> Hi Vít,
> 
> > Ruby recently started to fail on F28 since this Koschei build 
> 
> Which version of the annobin package are you using ?

$ rpm -q annobin
annobin-5.1-1.fc28.x86_64

> > [ The build fails at this
> > line [2], where the "eu-readelf" output is processed.
> 
> Would it be possible for you to upload the binary file that is being
> processed at this point ?
> 
> Also - do you get similar problems if you use the readelf program from
> the binutils package instead of eu-readelf ?

This is relevant part of the readelf output:

~~~
  GA*GOW:0x00000000044aa 0x00000000     OPEN
    Applies to region from 0x2da30 to 0x2dc88
  GA*<stack prot>0xffffffffffffffff 0x00000000  OPEN
    Applies to region from 0x2da30 to 0x2dc88
  GA!stack_clash:false 0x00000000       OPEN
    Applies to region from 0x2da30 to 0x2dc88
  GA*cf_protection:0x001 0x00000000     OPEN
    Applies to region from 0x2da30 to 0x2dc88
~~~

Created attachment 1416729 [details]
Faulty libruby

(In reply to Nick Clifton from comment #7)
> > Not sure if this is really annobin but this is my best guess.
> 
> It probably is annobin's fault, somehow, but in order to find out what
> is causing it, it would be really helpful to have a small, reproducible
> test case.  Is there any change that you could capture the compilation 
> that is producing the binary that contains the bogus annobin note ?

You should be able to reproduce it locally:

~~~
fedpkg co ruby
cd ruby
fedpkg srpm
mock -r fedora-28-x86_64 ruby-2.5.0-90.fc28.src.rpm
~~~

(In reply to Vít Ondruch from comment #10)
 
Hi Vit,

  OK, following those directions I was able to reproduce the problem.
  I was able to develop a workaround by editing the test_systemtab.rb script
  and changing:

# Detect probes in resulting library.
get_probes_detected = %r{
^\s*Provider:\s+ruby,\s+Name:\s+(\S+),\s+.*$
}

probes_detected = `eu-readelf -n "#{LIBRUBY_SO}"`

  to:

# Detect probes in resulting library.
get_probes_detected = %r{
^\s*Name:\s+(\S+)$
}

probes_detected = `readelf -n "#{LIBRUBY_SO}"`

  (ie using the readelf from the binutils package).

  The fix, IMHO, is for eu-readelf to either interpret annobin notes
  in the same way as the binutils readelf, and/or display non-printing
  characters as escape sequences.  (This would be a good thing even if
  the annobin notes did not exist as there can always be corrupt binaries
  containing corrupt notes).

  In the meantime I will add a patch to annobin so that it no longer
  records an unknown stack-protection setting as -1, but instead uses 0.
  This should prevent the generation of the notes that eu-readelf does not
  like.

Cheers
  Nick

Hi Vit,

  I have built annobin-5.2-1.fc28 (and annobin-5.2-1.fc29) which should
  no longer generate the note that is confusing eu-readelf.  Please give
  it a go.

Cheers
  Nick

Hi Nick,

I tried build of Ruby in F28 mock manually installing the recent build of annobin-5.2-1.fc28 and the build passed. The build is still passing on Rawhide. So it should be good on Ruby side.

Will you submit update for F28? And possibly buildroot override? Pavel Valena is working on Ruby updates, so it will soon become blocker for us.

Thx

annobin-5.2-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-77a311c2e5

annobin-5.2-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-77a311c2e5

annobin-5.2-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.