Re: rpmlint+readelf corrupted interpreter on generated binaries

Hi Mark, But I also think this is a bug in binutils readelf (CCing nickc). It really should not even try to print the "interpreter" of a separate debuginfo file. Well yes and no. One of the main uses of readelf is to inspect potentially broken or corrupt ELF files, so displaying the contents

Re: RISC-V ABI issue with ULEB128

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 th

Re: RISC-V ABI issue with ULEB128

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=73d931e560059a87d76f528fafbb4

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

> 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 se

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

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 controlli

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

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

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

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

Re: more distinct default bash prompt?

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: prom

Re: Maintanenace of redhat-rpm-macros

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 deve

Re: annobin breaks reproducibility?

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

Re: annobin breaks reproducibility?

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-

Re: No debugsource generated, weird DWARF errors

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 l

Re: No debugsource generated, weird DWARF errors

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 wa

Re: No debugsource generated, weird DWARF errors

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

Re: No debugsource generated, weird DWARF errors

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 dev

Re: No debugsource generated, weird DWARF errors

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 t

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

*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.fedo

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

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

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

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

Re: change in -fpic handling?

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 sec

Re: change in -fpic handling?

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

Re: change in -fpic handling?

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 _

Re: change in -fpic handling?

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

Re: F29 System Wide Change: Binutils 2.31

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 r

Re: F29 System Wide Change: Binutils 2.31

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. T

Re: RFH: Annotating ELF binaries

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

Re: RFH: Annotating ELF binaries

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

Re: RFH: Annotating ELF binaries

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 attrib

RFH: Annotating ELF binaries

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

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