Re: RISC-V ABI issue with ULEB128

[Nick Clifton]

Hi David,


binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it
as failed. The failures don't seem to be related to binutils package
itself. Seems like CI test is/was broken, or maybe a temporary network
issue, or something else.


It looks like rpminspect does not like two of the licenses used
by the binutils:

  BAD
  Unapproved license in binutils-2.41-19.fc40.src:
  GPL-2.0-or-later LGPL-2.1-or-later

Which seems wrong to me, since they are listed in the allowed
licenses list for Fedora.  I'll ask David Cantrell about it.

Cheers
  Nick

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RISC-V ABI issue with ULEB128

[Nick Clifton]

Hi David, Hi Florian,


Here's the bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=31179
RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects

It refers to this change in binutils 2.41:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc


FYI, a second patch is also needed: "RISC-V: Clarify the behaviors of SET/ADD/SUB 
relocations."
This is commit: 2029e13917d53d2289d3ebb390c4f40bd2112d21



In Fedora/RISCV we typically end up using the latest available
binutils. We are slightly different from upstream/normal Fedora.


I have now backported both of the above commits to rawhide binutils.
Build: binutils-2.31-18.fc40

Cheers
  Nick

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

> Can you please mention which option disables
> which error(s) explicitly in the Change?

Done.  

I have added the text to the Scope section in the notes for Other Developers. 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

Hi Dominik,

> Does the `--no-warn-rwx-segments` disable erroring out on both loadable
> rwx segments and tls rwx segments?

Yes.

At the time I wrote the feature I did consider having separate options for the 
two tests, but it seemed like overkill, so I decided to go with just a single 
controlling option.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

The warnings mentioned in the blog were added to the 2.39 release of the GNU 
Binutils, so they should potentially be present in the build logs of any 
package built for f38 or later.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Linker Error on Security Issues (System-Wide)

[Nick Clifton]

You can test for problems by searching the build logs for warnings from the 
linker: 

  "has a LOAD segment with RWX permissions" 
  "has a TLS segment with execute permission"
  "missing .note.GNU-stack section implies executable stack"

There are also two related warning messages, although these would not be 
candidates for conversion into errors because they represent positive action by 
the compiler and/or builder:
 
  "requires executable stack (because the .note.GNU-stack section is 
executable)"
  "enabling an executable stack because of -z execstack command line option"

Alternatively a package builder could add "-Wl,--fatal-warnings" to their final 
compilation command line, which would force all linker warning messages to be 
treated as errors.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: more distinct default bash prompt?

[Nick Clifton]

What do people think overall? Are there other pros and cons of a color prompt?
Any better ideas or direction?


I like the idea of using tput to get the correct strings for
setting different terminal effects, so I now use:

  # Success prompt:
  prompt_term[0]=$(tput bold)

  # Fail prompt:
  prompt_term[1]=$(tput setaf 1)  # red

  # Turn off all attributes
  prompt_term[2]=$(tput sgr0)

  # Make the prompt reflect the exit status of the last command
  export PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'" ==> "

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Maintanenace of redhat-rpm-macros

[Nick Clifton]

Hi Guys,

If it helps I would be happy to volunteer to be a co-maintainer, especially
when it comes to assembler and linker command line options...

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: annobin breaks reproducibility?

[Nick Clifton]

Hi Frédéric,


I think this is indeed the right choice and probably the more relevant info 
with respect the original source file. If you need some help for testing/fixing 
that, please don't hesitate. I would be happy to help. I'm also on IRC 
#fedora-devel.


Are you able to test using F34 rpms ?  I have updated annobin package
for F34, but due to the block on package updates getting the stable tag
it is not yet present in the official repository.  But you can download
the 9.65-1.fc34 build from here:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1721032

My testing showed that looking for a period in the filename was not
reliable however, so instead I have just gone for a fixed filename
(annobin_lto).  I *hope* that this will not cause problems with big
builds using lots of object files, but if you do encounter any problems
please let me know.

Cheers
  Nick

PS.  The rawhide annobin has not been updated because of a problem
with clang's c++ headers.  I am waiting for this bug to be fixed...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: annobin breaks reproducibility?

[Nick Clifton]

Hi Frédéric,

I'm currently working on reproducibility for Fedora packages and I'm hitting an issue with lto/annobin. 



     35: 2af0 0 NOTYPE  LOCAL  HIDDEN    13 
.annobin_dummyqbs_drv.so.MDkv6z.ltrans0.o



Do you have any idea what would be the best strategy to fix that? lto-wrapper 
or in the annobin plugin?


Ah - so LTO is using temporary file names and these are being picked up by
the annobin plugin and inserted into the output binary.  I think that it
is safe to assume that LTO should not be using fixed file names, given the
potential security and parallel compilation implications, so the place to
fix this is in the annobin plugin.

So the question becomes, what name should the annobin plugin use ?

Currently the plugin uses the first name in the in_fnames[] array, if it is
available and main_input_filename otherwise.  The name chosen does not have
to be unique however, although it certainly helpful for debugging if it can
be related back to the input source file.  Perhaps if the compiler is in LTO
mode then the plugin should terminate the name chosen at the first period ?
(So "dummy_drv.so.MDkv6z.ltrans.0" becomes "dummy_drv.so").

What do you think ?

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Richard,

> guestfish on x86-64 was failing for me with something that looks a lot
> like the same PLT problem.  But it's not aarch64.  Very easy to
> reproduce, see:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ULGH5JYL7MHKDKTINJLOEN2QG6LOHWH7/

This looks like it might be the binutils/LTO thing:

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

The patches for that PR are now in rawhide and a rebuild is taking place,
(It has not finished yet as builds are taking a very long time today).
Look for binutils-2.35-8.fc33 to appear in the buildroot and then try again.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

>> Yes, because the commit adding the DWARF 4 patch has also
>> turned LTO back on...

*double sigh*.  Yes I was trying to fix the LTO bug at the same time, 
and forgot that I had re-enabled it in my local copy of the rawhide
sources in order to investigate the problems.

That binutils was rebuilt (thanks to Richard Jones) and I have now
built an even newer one which contains a fix for AArch64 PLT problems.
Both of these are built with LTO disabled, so the bug should not affect them.

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.

Yes - it was a silly snafu.  I set the default to 4 but the tests are expecting 
3.

I have now updated the patch and a new binutils (2.23-5.fc33) is building...

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

> But... in 2.35 you can give the DWARF level you want.
> The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> dwarf_level is never set! And then gas will happily create an
> .debug_info section with DWARF CUs that have a version of zero (!).

Doh!

> This, defaulting to version 4. Fixes it for me:
> 
> diff --git a/gas/as.c b/gas/as.c
> index 4c5881abd88..c2da78870ef 100644
> --- a/gas/as.c
> +++ b/gas/as.c
> @@ -103,7 +103,7 @@ int verbose = 0;
>  int flag_dwarf_cie_version = -1;
>  
>  /* The maximum level of DWARF DEBUG information we should manufacture.  */
> -unsigned int dwarf_level = 0;
> +unsigned int dwarf_level = 4;
>  
>  #if defined OBJ_ELF || defined OBJ_MAYBE_ELF
>  int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON;

I will apply this patch to the rawhide binutils (and the upstream binutils 
sources).

Thanks for finding the problem Mark.

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: annobin says a lot "ICE: attempting to access a gcc command line option that is not stored in global_options"

[Nick Clifton]

*sigh*   Sorry guys.  Please try using annobin-9.21.1-fc33.  This should fix 
the issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Nick Clifton]

Hi Paolo,

> I can maintain nasm if no one else wants to take it.

Please do, if that it what you want.  However I think that it
might be better in the long run if we can retire nasm (and yasm
too) and instead replace them with gas.  

Cheers
  Nick

PS.  In case there is someone reading this email who is unfamiliar
with gas, it is the GNU assembler from the binutils package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Nick Clifton]

Hi Florian,

>> Linking dist/build/tests-asn1-encoding/tests-asn1-encoding ...
>> /tmp/ghc8eea_0/ghc_2.o(.gnu.build.attributes..text.startup+0x18): error: 
>> relocation refers to local symbol "" [11], which is defined in a discarded 
>> section
>>    section group signature: "(null)"

This should now be fixed.  (binutils-2.31.1-3.fc29)

The problem was an extension of the problem originally reported in BZ 1600431.
The gold linker is complaining about relocations from the annobin notes to
discarded code sections.  This particular version of the problem arose because
I patched annobin to create section groups containing both the notes and the
code, but I did not update the patch to gold to allow it to detect these
sections.  Anyway it should all be fixed now.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YCDCLJ6BBGDCVWTJGQR3A3EZJEYWHDN2/

Re: change in -fpic handling?

[Nick Clifton]

Hi Florian,

>>  * Weak symbols are not generated by the annobin plugin
>>    when compiling with -ffunction-sections.
>>
>>    There was no point really.  Linker garbage collection will not
>>    discard sections if they have annobin notes against them, since
>>    the code section and the note section are not in a section group.
>>       Really this is a gcc problem.  If it created a section group 
>> for
>>    sections created by the -ffunction-sections option, then annobin
>>    could add the notes into this group and linker garbage collection
>>    would discard the lot.
>>
>>    Note - annobin does still generate weak symbols for linkonce
>>    sections, since these can and will be discarded by the linker.
>>    The symbols still get into the dynamic symbol table, but they
>>    are hidden.  Not sure if this makes much difference however.
> 
> Doesn't this keep all function sections in the final executable because they 
> are now permanently referenced?

Yes. :-(  Well yes, but only if they have different optimization attributes from
the rest of the compilation unit that they are in.  IE, only if annobin notes 
are
generated for them.  I have tried to find a away around this, but the only 
solution
that I can come up with is to properly use section groups to contain the 
function
section, any debug sections and the annobin note section.  To do this we first 
have
to start with gcc, and persuade it to emit the necessary assembler to define a 
section group.  As soon as I have a free moment I plan to create a patch to do 
this.


> 
>>  * The annobin plugin will now only reference symbols that it
>>    creates, and all of these symbols now have a ".annobin_" prefix
>>    in order to avoid potential collisions with symbols defined
>>    elsewhere in the executable.
> 
> Can this still cause symbol clashes if two linkonce sections (of different 
> names) contain functions which receive annobin annotations?

It shouldn't.  The annobin symbol is basically the section name with ".annobin_"
as a prefix.  So two difference linkonce sections should also have two different
annobin symbols.



> Anyway, looks like these annobin changes exposed a binutils bug:
> 
>   

Yes. I forgot to check ifunc functions.  Doh.
This should now be fixed though...

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/42G3TFEGT7ZTBKHLEZ4ZL6H563B5IHUU/

Re: change in -fpic handling?

[Nick Clifton]

Hi Dave, Hi Florian,

  Right - there is a new annobin rpm available - annobin-8.0-1.el8 - which
  has these changes:

* Weak symbols are not generated by the annobin plugin
  when compiling with -ffunction-sections.

  There was no point really.  Linker garbage collection will not
  discard sections if they have annobin notes against them, since
  the code section and the note section are not in a section group.
  
  Really this is a gcc problem.  If it created a section group for
  sections created by the -ffunction-sections option, then annobin
  could add the notes into this group and linker garbage collection
  would discard the lot.

  Note - annobin does still generate weak symbols for linkonce
  sections, since these can and will be discarded by the linker.
  The symbols still get into the dynamic symbol table, but they
  are hidden.  Not sure if this makes much difference however.


* The annobin plugin will now only reference symbols that it 
  creates, and all of these symbols now have a ".annobin_" prefix 
  in order to avoid potential collisions with symbols defined
  elsewhere in the executable.


  I hope that these changes address the immediate issue of libxsmm not 
  compiling.

  Longer term I need to work with the gcc maintainers to get section
  groups generated for function sections.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GTDIIJ7S6YYV55EQFJ4FRI57VWT7HJES/

Re: change in -fpic handling?

[Nick Clifton]

Hi Florian,

> Superficially, this will work.
> 
> But I'm a bit worried that the .weak still makes the symbol global, so that 
> it ends up in the dynamic symbol table.

Hmm, if I make the symbols hidden rather than weak, will that work ?

I need to investigate...

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JQQG4ADGC35WZABT4L3C6AYL7I23TBSV/

Re: change in -fpic handling?

[Nick Clifton]

Hi Florian, Hi Dave,


>>    /usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86_64_PC32 
>> against symbol `libxsmm_crc32_u64' can not be used when making a shared 
>> object; recompile with -fPIC

> GCC emits calls to the function using:
> 
>     call    libxsmm_crc32_u64
> 
> This is a direct call, not through the PLT, and is allowed under the default 
> x86-64 memory model for local (static) functions because all code fits into 2 
> GiB.
> 
> But annobin generates this:
> 
>     .pushsection .text.libxsmm_crc32_u64
> libxsmm_crc32_u64_end:
>     .popsection
>     .pushsection .gnu.build.attributes
>     .weak libxsmm_crc32_u64
>     .weak libxsmm_crc32_u64_end
>     .popsection
> 
> The .weak directive makes the symbol global, so it can be interposed from 
> other modules, and the direct call shown above is no longer permitted.
> 
> Nick, this looks like an annobin bug.  This is really, really problematic 
> from an ABI perspective.

OK - so if I change annobin so that it creates its own function start symbol, 
eg libxsmm_crc32_u64_start and then it references this symbol in the .weak
directive, (instead of libxsmm_crc32_u64), then everything should be OK right ?
Since the new symbol will be exclusive to annobin, it will not be used in any
function calls, and so no R_X86_64_PC32 relocs should be generated against it.

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4UZIXGHYAVUGQEYWM2FVZFYOBPX6VFUH/

Re: F29 System Wide Change: Binutils 2.31

[Nick Clifton]

Hi Zbigniew,

>>> Also, what is the relationship between
>>> https://fedoraproject.org/wiki/Changes/BINUTILS230
>>> and 
>>> https://fedoraproject.org/wiki/Changes/BINUTILS231
>>
>> BINUTILS230 was the change request to bring in FSF binutils 2.30.  This
>> is the version that is currently used in rawhide.
>>
>> BINUTILS231 is the change request to bring in FSF binutils 2.31.  The
>> 2.31 release has not actually happened yet - it is scheduled for July 7
>> - but if it does happen in time then I would like to get it into rawhide
>> before the mass rebuild happens.  Then if there are any problems they
>> should show up quickly.
> 
> But changes are specific to a Fedora release. If users see both changes
> in the release notes for F29 they will be justifiably confused. So I think
> BINUTILS230 should be automatically dropped (superseded) if BINUTILS231
> makes it into F29.

Oh, right, now I understand.  I agree, we should drop BINUTILS230 if 
BINUTUILS231
makes it in.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HECVLJ6IEUS7KOBJSZ4OUTUXRYWPTDCH/

Re: F29 System Wide Change: Binutils 2.31

[Nick Clifton]

Hi Zbigniew,

>> Do you foresee any significant issues with this version upgrade in the 
>> mass rebuild? 

No.  I am currently testing the 2.31 sources on the FSF branch, but so far
everything looks good.

>> Anything in particular that maintainers and upstreams
>> should looks at?

I hope not.  There have been problems in the past when rebasing the binutils,
so I cannot guarantee that there will be no issues, but I will do my best to
make sure that the change does not cause any problems, and that maintainers
and upstreams do not even know that it has happened.

> Also, what is the relationship between
> https://fedoraproject.org/wiki/Changes/BINUTILS230
> and 
> https://fedoraproject.org/wiki/Changes/BINUTILS231

BINUTILS230 was the change request to bring in FSF binutils 2.30.  This
is the version that is currently used in rawhide.

BINUTILS231 is the change request to bring in FSF binutils 2.31.  The
2.31 release has not actually happened yet - it is scheduled for July 7
- but if it does happen in time then I would like to get it into rawhide
before the mass rebuild happens.  Then if there are any problems they
should show up quickly.

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3REQAFASWKTQ7BHQFWDNMVKOTZKCAVAE/

Re: RFH: Annotating ELF binaries

[Nick Clifton]

Hi Carlos,

> I've added 2 questions to the Toolchain/Watermark wiki but will post them
> here for posterity:

Thanks - I'll try answering them here first, and if my answers make sense
then I will update the wiki.

> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what 
> you are proposing?

Good question, and unfortunately I do not know the answer.  The problem
is, I have been unable to locate any documentation that describes 
SHT_GNU_ATTRIBUTES and how it is supposed to be used.

I think that the two schemes are quite similar, although this new proposal
is intended to be able to cope with attributes that only apply to part of
an executable and not necessarily the executable as a whole.  (Also, IMHO,
my proposal has better documentation...)


> (2) What is being done to ensure the attributes are space and time
> efficient for dynamic link comparison in the dynamic linker? 
> Speed of checking 10,000 DSOs (scalability) for ABI compatibility is 
> going to be a very important requirement.

I believe that H.J's design for the dynamic link notes does take efficiency
into consideration, but I will leave that for him to comment on further.

One thing that I have already done for the static notes is to implement a
new option for objcopy called "--merge-notes" which eliminates redundancies.
Theoretically this option could be extended to work with the dynamic notes
too, helping to make them as space efficient as possible.

Another possibility is that the linker could be extended so that when it
creates a dynamic executable it also inserts a "master" dynamic linker note,
which contains all of the information that the dynamic linker will need,
without it having to search through all of the shared libraries used by the
application.  (This does assume that the shared libraries examined at static
link time are the same ones that are loaded/used at dynamic link time).



> (b) Loadable notes and space/time efficiency vs. non-loadable notes and
> static analysis tools.
> 
> Run-time checking of properties is radically different from offline
> checking of properties and we absolutely need two different designs to
> meet these needs. However, if we could weld the two together in a compatible
> way, that would be great. For example if the dynamic loader could map from
> a 'run-time property' to a 'link-time property' to increase the verbosity
> of the error in a failure scenario, then that might be beneficial.

I think that this might not be easy to do in a way that both imposes a low
code-increase cost on the dynamic linker and a keep-the-dynamic-link-notes-small
space requirement.  There is no harm in investigating though.

> If we
> could translate 'link-time notes' into 'a collection of run-time properties' 
> in
> a semi-automatic fashion given strict rules about the notes application,
> then that would also be awesome.

Now this might well be feasible.  I am thinking of another new option to objcopy
here that examines the static notes and generates dynamic notes from them.  This
should be quite straightforward, provided that the static notes have captures
the right information.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFH: Annotating ELF binaries

[Nick Clifton]

Hi H.J.

> We have 2 different proposals for program properties.  Mine:
> 
> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html
> 
> has a much smaller scope.  New features on upcoming Intel platforms,
> like 5-level paging, need this extension for loader decision at run-time.
> How should we move forward with program property extensions?

I would like to combine the two approaches.  Ie use your notes for
properties that need to be examined at run-time (specifically the
loader, although I imagine that the application itself might be 
interested in reading its own notes).  Plus use the note scheme I
am proposing for static analysis tools.

I am currently using a gcc plugin to generate the notes, and I think
that this should be extendable to generate your notes as well.  (Using
a plugin is advantageous in that it is not tied to the latest gcc release.
It can be built to run with older gcc's, and it can be updated 
independently of the gcc release cycle).

What do you think ?

Cheers
  Nick

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFH: Annotating ELF binaries

[Nick Clifton]

Hi Tristan,

>> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects

> This will generalise attributes used by some architectures (ppc, arm), won't 
> it ?

Yes.  Or at least it would if implemented as currently proposed.  Maybe a better
solution would be to only record attributes where they are not already covered 
by 
some target specific solution.

Personally I would prefer a nice, generalised solution, but the current target 
specific attributes are mandated by the particular ABIs and so presumably are 
not
going to go away.

Cheers
  Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RFH: Annotating ELF binaries

[Nick Clifton]

Hello Everyone,

  We (the tools team at Red Hat) are working on a project to add
  annotations to ELF binaries, so that we can answer various questions
  about them.  We have set up a wiki page about the project here:

https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects

  We would very much like this to be something more than just an
  internal project, and so we are reaching out to you for your opinions,
  suggestions and advice.  If you are interested in being able answer
  questions such as 'how was this function compiled ?' or 'is this
  library compatible with this application ?' then please take a minute
  to have a look at the proposal.

  Thanks very much.

Cheers
  Nick Clifton
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Change to DSO-linking semantics of the compiler

[Nick Clifton]

Hi Guys,

>> SystemTap is failing on pthread_cancel, which is odd since we have no
>> mention of pthread in our own sources.  It seems to be pulled in by some
>> headers in the STL.  Consider this minimal example:
>>
>> $ cat string.cxx
>> #include
>> int main()
>> {
>>  return std::string("foo").length() != 3;
>> }
>> $ g++ -c string.cxx
>> $ nm -C string.o
>>   w pthread_cancel
>> $ g++ -o string string.o
>>
>> This is fine, becauses __gthread_active_p is just using the fact that
>> the weak pthread_cancel symbol becomes 0 if libpthread isn't linked.
>>
>> But if one of your dependent libraries uses pthreads, suddenly the main
>> executable gets the normal pthread_cancel symbol too, and the new linker
>> serves up death:
>>
>> $ g++ -o string string.o -ldb
>> /usr/bin/ld.bfd: string.11980.test: undefined reference to symbol
>> 'pthread_cancel@@GLIBC_2.2.5'
>> /usr/bin/ld.bfd: note: 'pthread_cancel@@GLIBC_2.2.5' is defined in DSO
>> /lib64/libpthread.so.0 so try adding it to the linker command line

But, you have added an explicit dependency upon libdb to your executable 
by mentioning -ldb on the gcc command line.  Therefore libdb will be 
loaded at execution start-up.  But libdb has a dependency upon 
libpthread, so that library will also be loaded at execution start-up. 
Hence when you run 'string' the pthread_cancel symbol will be resolved 
and so 'string' really does now have a resolved reference to 
pthread_cancel.  Hence the linker is correct in complaining that you 
have a reference to a symbol that is defined in a library which have not 
included on the linker command line.

At least that is how I see it at the moment.

The point being that because you are using -ldb you have inherited a 
need for the pthread library as well.  Hence this works:

   g++ o string string.o -ldb -lpthread

Cheers
   Nick
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel