[Touch-packages] [Bug 2059856]
The master branch has been updated by Tom Tromey
:
https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=b1741ab0dafd899889faab6e862094a325a6b83c
commit b1741ab0dafd899889faab6e862094a325a6b83c
Author: Tom Tromey
Date: Sat Mar 30 13:48:30 2024 -0600
libiberty: Invoke D demangler when --format=auto
Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names. However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low. The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).
This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276
libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/2059856
Title:
gdb 10.0 fails to examine any global variables in D programs
Status in gdb:
Fix Released
Status in gdb package in Ubuntu:
New
Bug description:
[ Impact ]
* GDB 10.0 introduced a regression where it cannot inspect any global
variables in any D programs compiled by any D compiler.
* LDC2 and GDC upstream stated Focal does not have such a problem and stuck
to this release for their test images.
[ Test Plan ]
Considering the following D program:
```
module t;
class uv {
int i;
}
__gshared uv i;
int main() {
i = new uv();
return 0; // #break
}
```
If you build it using `gdc -g -O0 t.d -o t` or `ldc2 -o t.o t.d -g`,
run the GDB using the following commands ...
```
b t.d:10
p t.i
```
... you will notice GDB will complain that "'t.i' has unknown type;
cast it to its declared type."
[ Where problems could occur ]
* The fix consists of a single line change to the demangler. The worst-case
scenario would be breaking the demangling functionality of other programming
languages. However, the newer D ABI uses a symbol mangling scheme that is very
difficult to confuse with other programming languages.
* Incorrect symbol de-mangling may also cause user confusion. However, the
patch fixed a fundamental usability issue.
[ Other Info ]
* Initial discussion in the LDC2 bug tracker:
https://github.com/ldc-developers/ldc/issues/4389
To manage notifications about this bug go to:
https://bugs.launchpad.net/gdb/+bug/2059856/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1933775]
The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c608b57f77a47179899666940c3b8b6a2e5435b2 commit r14-9550-gc608b57f77a47179899666940c3b8b6a2e5435b2 Author: Jonathan Wakely Date: Thu Feb 29 17:13:49 2024 + libstdc++: Suppress deprecation messages from [PR101228] libstdc++-v3/ChangeLog: PR libstdc++/101228 * include/pstl/parallel_backend_tbb.h (TBB_SUPPRESS_DEPRECATED_MESSAGES): Define before including then undef afterwards. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tbb in Ubuntu. https://bugs.launchpad.net/bugs/1933775 Title: libgcc-s1 and libstdc++6 depend on broken libtbb2 package Status in gcc: In Progress Status in tbb package in Ubuntu: New Bug description: The gcc-11 source package produces libgcc-s1 and (I think?) libstdc++6. Both of these binary packages on Hirsute depend on libtbb2 version 2020.3-1. The latter contains deprecated APIs that create #pragma generated warnings whenever is included. See upstream for discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/1933775/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2023437]
The binutils-2_40-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=03f49a0619c5598eea80511efef5a88c4f7bb293 commit 03f49a0619c5598eea80511efef5a88c4f7bb293 Author: Alan Modra Date: Wed Jun 21 22:44:09 2023 +0930 PR30536, ppc64el gold linker produces unusable clang-16 binary In commit 0961e631575b, the fix for PR30217, make_lplt_section and make_brlt_section were changed to use rela_dyn_ rather than their own separate dynamic reloc sections. This fails miserably whenever brlt_ is needed for long branches, due to needing to iterate sizing and thus reset brlt_ sizes. PR 30536 PR 30217 * powerpc.cc (Target_powerpc::make_brlt_section): Don't use rela_dyn_. (cherry picked from commit dc808a2ebab337b5517add4c1aad298cf836c239) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/2023437 Title: ppc64el gold linker produces unusable clang-16 binary Status in binutils: Fix Released Status in binutils package in Ubuntu: New Bug description: root@Unimatrix08-Jammy:/clang# /usr/bin/g++-12 -O3 -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fdebug-prefix-map=/llvm-toolchain-16-16.0.5/build-llvm=build-llvm -fdebug-prefix-map=/llvm-toolchain-16-16.0.5/= -no-canonical-prefixes -ffile-prefix-map=/llvm-toolchain-16-16.0.5/build-llvm=build-llvm -ffile-prefix-map=/llvm-toolchain-16-16.0.5/= -no-canonical-prefixes -fno-common -Woverloaded-virtual -fno-strict-aliasi ng -O3 -DNDEBUG -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--build-id -fuse-ld=bfd-Wl,--gc-sections tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/cc1gen_reproducer_main.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/clang-driver.cpp.o -o bin/clang-16-bfd -Wl,-rpath,"\$ORIGIN/../lib:" lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMAnalysis.a lib/libLLVMCodeGen.a lib/libLLVMCore.a lib/libLLVMipo.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTargetParser.a lib/libLLVMTransformUtils.a lib/libLL VMVectorize.a lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a lib/libclangFrontend.a lib/libclangFrontendTool.a lib/libclangSerialization.a lib/libLLVMAsmPrinter.a lib/libLLVMGlobalISel.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libclangCodeGen.a lib/libLLVMCoverage.a lib/libLLVMLTO.a lib/libLLVMExtensions.a lib/libPolly.a lib/libPollyISL.a lib/libLLVMPasses.a lib/libLLVMCodeGen.a lib/libLLVMObjCARCOpts.a lib/libLLVMTarget.a lib/libLLVMCoroutines.a lib/libLLVMipo.a lib/libLLVMInstrumentation.a lib/libLLVMVectorize.a lib/libLLVMBitWriter.a lib/libLLVMLinker.a lib/libLLVMIRPrinter.a lib/libclangExtractAPI.a lib/libclangRewriteFrontend.a lib/libclangARCMigrate.a lib/libclangStaticAnalyzerFrontend.a lib/libclangStaticAnalyzerCheckers.a lib/libclangStaticAnalyzerCore.a lib/libclangCrossTU.a lib/libclangIndex.a lib/libclangFrontend.a lib/libclangDriver.a lib/libLLVMWindowsDriver.a lib/libLLVMOption.a lib/libclangParse .a lib/libclangSerialization.a lib/libclangSema.a lib/libclangAnalysis.a lib/libclangASTMatchers.a lib/libLLVMFrontendHLSL.a lib/libclangEdit.a lib/libclangSupport.a lib/libclangAST.a lib/libLLVMFrontendOpenMP.a lib/libLLVMScalarOpts.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMSymbolize.a lib/libLLVMDebugInfoDWARF.a lib/libLLVMDebugInfoPDB.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMIRReader.a lib/libLLVMBitReader.a lib/libLLVMAsmParser.a lib/libLLVMTextAPI.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMCore.a lib/libLLVMBinaryForm
[Touch-packages] [Bug 2023437]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=dc808a2ebab337b5517add4c1aad298cf836c239 commit dc808a2ebab337b5517add4c1aad298cf836c239 Author: Alan Modra Date: Wed Jun 21 22:44:09 2023 +0930 PR30536, ppc64el gold linker produces unusable clang-16 binary In commit 0961e631575b, the fix for PR30217, make_lplt_section and make_brlt_section were changed to use rela_dyn_ rather than their own separate dynamic reloc sections. This fails miserably whenever brlt_ is needed for long branches, due to needing to iterate sizing and thus reset brlt_ sizes. PR 30536 PR 30217 * powerpc.cc (Target_powerpc::make_brlt_section): Don't use rela_dyn_. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/2023437 Title: ppc64el gold linker produces unusable clang-16 binary Status in binutils: Fix Released Status in binutils package in Ubuntu: New Bug description: root@Unimatrix08-Jammy:/clang# /usr/bin/g++-12 -O3 -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fdebug-prefix-map=/llvm-toolchain-16-16.0.5/build-llvm=build-llvm -fdebug-prefix-map=/llvm-toolchain-16-16.0.5/= -no-canonical-prefixes -ffile-prefix-map=/llvm-toolchain-16-16.0.5/build-llvm=build-llvm -ffile-prefix-map=/llvm-toolchain-16-16.0.5/= -no-canonical-prefixes -fno-common -Woverloaded-virtual -fno-strict-aliasi ng -O3 -DNDEBUG -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--build-id -fuse-ld=bfd-Wl,--gc-sections tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/cc1gen_reproducer_main.cpp.o tools/clang/tools/driver/CMakeFiles/clang.dir/clang-driver.cpp.o -o bin/clang-16-bfd -Wl,-rpath,"\$ORIGIN/../lib:" lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMAnalysis.a lib/libLLVMCodeGen.a lib/libLLVMCore.a lib/libLLVMipo.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTargetParser.a lib/libLLVMTransformUtils.a lib/libLL VMVectorize.a lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a lib/libclangFrontend.a lib/libclangFrontendTool.a lib/libclangSerialization.a lib/libLLVMAsmPrinter.a lib/libLLVMGlobalISel.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libclangCodeGen.a lib/libLLVMCoverage.a lib/libLLVMLTO.a lib/libLLVMExtensions.a lib/libPolly.a lib/libPollyISL.a lib/libLLVMPasses.a lib/libLLVMCodeGen.a lib/libLLVMObjCARCOpts.a lib/libLLVMTarget.a lib/libLLVMCoroutines.a lib/libLLVMipo.a lib/libLLVMInstrumentation.a lib/libLLVMVectorize.a lib/libLLVMBitWriter.a lib/libLLVMLinker.a lib/libLLVMIRPrinter.a lib/libclangExtractAPI.a lib/libclangRewriteFrontend.a lib/libclangARCMigrate.a lib/libclangStaticAnalyzerFrontend.a lib/libclangStaticAnalyzerCheckers.a lib/libclangStaticAnalyzerCore.a lib/libclangCrossTU.a lib/libclangIndex.a lib/libclangFrontend.a lib/libclangDriver.a lib/libLLVMWindowsDriver.a lib/libLLVMOption.a lib/libclangParse .a lib/libclangSerialization.a lib/libclangSema.a lib/libclangAnalysis.a lib/libclangASTMatchers.a lib/libLLVMFrontendHLSL.a lib/libclangEdit.a lib/libclangSupport.a lib/libclangAST.a lib/libLLVMFrontendOpenMP.a lib/libLLVMScalarOpts.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMSymbolize.a lib/libLLVMDebugInfoDWARF.a lib/libLLVMDebugInfoPDB.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMIRReader.a lib/libLLVMBitReader.a lib/libLLVMAsmParser.a lib/libLLVMTextAPI.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMRemarks.a lib/libLLVMBitstreamReader.a lib/libclangFormat.a lib/libcla
[Touch-packages] [Bug 1940996]
The release/2.34/master branch has been updated by Florian Weimer : https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=86a701a20479dfbc23540b3143fd5b28660a2447 commit 86a701a20479dfbc23540b3143fd5b28660a2447 Author: Paul Eggert Date: Tue Sep 21 07:47:45 2021 -0700 regex: copy back from Gnulib Copy regex-related files back from Gnulib, to fix a problem with static checking of regex calls noted by Martin Sebor. This merges the following changes: * New macro __attribute_nonnull__ in misc/sys/cdefs.h, for use later when copying other files back from Gnulib. * Use __GNULIB_CDEFS instead of __GLIBC__ when deciding whether to include bits/wordsize.h etc. * Avoid duplicate entries in epsilon closure table. * New regex.h macro _REGEX_NELTS to let regexec say that its pmatch arg should contain nmatch elts. Use that for regexec, instead of __attr_access (which is incorrect). * New regex.h macro _Attr_access_ which is like __attr_access except portable to non-glibc platforms. * Add some DEBUG_ASSERTs to pacify gcc -fanalyzer and to catch recently-fixed performance bugs if they recur. * Add Gnulib-specific stuff to port the dynarray- and lock-using parts of regex code to non-glibc platforms. * Fix glibc bug 11053. * Avoid some undefined behavior when popping an empty fail stack. (cherry picked from commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1940996 Title: test failure - test-regex Status in grep: Fix Released Status in grep package in Ubuntu: New Bug description: 'test-regex' fails when building grep against glibc 2.34. Per commentary from grep upstream at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50069, the test failure can be attributed to skew between the glibc built-in regex and the one that is found in the grep source code. To manage notifications about this bug go to: https://bugs.launchpad.net/grep/+bug/1940996/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1958389]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=07c9f243b3a12cc6749bc02ee7b165859979348b commit 07c9f243b3a12cc6749bc02ee7b165859979348b Author: Alan Modra Date: Fri Jan 28 14:29:34 2022 +1030 PR28826 x86_64 ld segfaults building xen Fallout from commit e86fc4a5bc37 PR 28826 * coffgen.c (coff_write_alien_symbol): Init dummy to zeros. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1958389 Title: Jammy builds of xen segfault, but only on launchpad x86 builders Status in binutils: In Progress Status in launchpad-buildd: New Status in binutils package in Ubuntu: New Status in xen package in Ubuntu: Invalid Status in binutils source package in Jammy: New Status in xen source package in Jammy: Invalid Status in binutils package in Debian: New Bug description: FTBFS in Jammy on LP infra: https://launchpadlibrarian.net/580924961/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa4_BUILDING.txt.gz https://launchpadlibrarian.net/581060687/buildlog_ubuntu-jammy-amd64.xen_4.16.0-1~ubuntu1~jammyppa6_BUILDING.txt.gz Related PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4760/+packages Summary: - Build reliably fails on LP - Build in local sbuild works reliably on my Laptop - Build in local VM (sizing like LP builders) works (other crashes but works) - Build on AMD server (chip more similar to LP) works reliably Failing step: On Launchpad build infrastructure it breaks on ld: $ x86_64-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0x82d04000 --stack=0,0 --heap=0,0 --section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 --minor-image-version=16 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp --build-id=sha1 -T efi.lds -N prelink.o /<>/xen/common/symbols-dummy.o -b pe-x86-64 efi/buildid.o -o /<>/xen/.xen.efi.0x82d04000.0 && : Segmentation fault (core dumped --- Steps to recreate (result depends on platform) # you can grab the package from https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/4760/+packages sudo vim /etc/apt/sources.list sudo apt update sudo apt dist-upgrade -y sudo apt build-dep xen sudo apt install flex bison python3-dev libpython3-dev dpkg-dev devscripts apport-retrace sudo mkdir /mnt/build sudo chmod go+w /mnt/build cd /mnt/build # copy in things from host scp xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0-1~ubuntu1~jammyppa6.debian.tar.xz xen_4.16.0.orig.tar.bz2 ubuntu@:/mnt/build dpkg-source -x xen_4.16.0-1~ubuntu1~jammyppa6.dsc xen_4.16.0 cd xen_4.16.0 dpkg-buildpackage -i -us -uc -b --- In a jammy VM 4cpu/8G I get some avx2 crashes but the build works: Jan 19 07:41:27 j kernel: x86_64-linux-gn[130016]: segfault at 0 ip 7f189432ef3d sp 7ffc8e2361d8 error 4 in libc.so.6[7f18941bb000+194000] Jan 19 07:41:27 j kernel: Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 00 fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66 #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74 74../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. (gdb) bt #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74 #1 0x7fa98d63c2d0 in ?? () from /lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so #2 0x7fa98d6021e8 in ?? () from /lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so #3 0x7fa98d602509 in coff_write_alien_symbol () from /lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so #4 0x7fa98d6033bd in _bfd_coff_final_link () from /lib/x86_64-linux-gnu/libbfd-2.37.50-system.20220106.so #5 0x562bdaaae3bf in ?? () #6 0x7fa98d2e8fd0 in __libc_start_call_main (main=main@entry=0x562bdaaad5e0, argc=argc@entry=8, argv=argv@entry=0x7ffc797f2968) at ../sysdeps/nptl/libc_start_call_main.h:58 #7 0x7fa98d2e907d in __libc_start_main_impl (main=0x562bdaaad5e0, argc=8, argv=0x7ffc797f2968, init=, fini=, rtld_fini=, stack_end=0x7ffc797f2958) at ../csu/libc-start.c:409 #8 0x562bdaaad515 in ?? () ^^ that is a different crash than on th LP builders ! And despite those crashes the build does appear to work oO?! The same crashes I see on my local sbuild runs, the full set of one build is Jan 19 07:39:02 Keschdeichel kernel: x86_64-linux-gn[4131180]: segfault at 0 ip 7f566e8b3f3d sp 7ffde04b75a8 error 4 in libc.so.6[7f566e74+194000] Jan 19 07:39:03 Keschdeichel kernel: x86_64-linux-gn[4131332]: segfault at 0 ip 7fbba26e4f3d sp 7fffab8a5b68 error 4 in libc.so.6[7fbba2571000+194000] Jan 19 07
[Touch-packages] [Bug 1940996]
The master branch has been updated by Paul Eggert : https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0b5ca7c3e551e5502f3be3b06453324fe8604e82 commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82 Author: Paul Eggert Date: Tue Sep 21 07:47:45 2021 -0700 regex: copy back from Gnulib Copy regex-related files back from Gnulib, to fix a problem with static checking of regex calls noted by Martin Sebor. This merges the following changes: * New macro __attribute_nonnull__ in misc/sys/cdefs.h, for use later when copying other files back from Gnulib. * Use __GNULIB_CDEFS instead of __GLIBC__ when deciding whether to include bits/wordsize.h etc. * Avoid duplicate entries in epsilon closure table. * New regex.h macro _REGEX_NELTS to let regexec say that its pmatch arg should contain nmatch elts. Use that for regexec, instead of __attr_access (which is incorrect). * New regex.h macro _Attr_access_ which is like __attr_access except portable to non-glibc platforms. * Add some DEBUG_ASSERTs to pacify gcc -fanalyzer and to catch recently-fixed performance bugs if they recur. * Add Gnulib-specific stuff to port the dynarray- and lock-using parts of regex code to non-glibc platforms. * Fix glibc bug 11053. * Avoid some undefined behavior when popping an empty fail stack. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1940996 Title: test failure - test-regex Status in grep: In Progress Status in grep package in Ubuntu: New Bug description: 'test-regex' fails when building grep against glibc 2.34. Per commentary from grep upstream at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50069, the test failure can be attributed to skew between the glibc built-in regex and the one that is found in the grep source code. To manage notifications about this bug go to: https://bugs.launchpad.net/grep/+bug/1940996/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1934505]
The gdb-11-branch branch has been updated by Simon Marchi
:
https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=ff32938d4471ebf6dce462934de8ab47f9fd5d66
commit ff32938d4471ebf6dce462934de8ab47f9fd5d66
Author: Simon Marchi
Date: Thu Jul 8 10:05:16 2021 -0400
gdb: don't set Linux-specific displaced stepping methods in
s390_gdbarch_init
According to bug 28056, running an s390x binary gives:
(gdb) run
Starting program: /usr/bin/ls
/home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550:
internal-error: displaced_step_prepare_status
linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion
`gdbarch_data->num_disp_step_buffers > 0' failed.
This is because the s390 architecture registers some Linux-specific
displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:
set_gdbarch_displaced_step_prepare (gdbarch,
linux_displaced_step_prepare);
set_gdbarch_displaced_step_finish (gdbarch,
linux_displaced_step_finish);
set_gdbarch_displaced_step_restore_all_in_ptid
(gdbarch, linux_displaced_step_restore_all_in_ptid);
But then the Linux-specific s390_linux_init_abi_any passes
num_disp_step_buffers=0 to linux_init_abi:
linux_init_abi (info, gdbarch, 0);
The problem happens when linux_displaced_step_prepare is called for the
first time. It tries to allocate the displaced stepping buffers, but
sees that the number of displaced stepping buffers for that architecture
is 0, which is unexpected / invalid.
s390_gdbarch_init should not register the linux_* callbacks, that is
expected to be done by linux_init_abi. If debugging a bare-metal s390
program, or an s390 program on another OS GDB doesn't know about, we
wouldn't want to use them. We would either register no callbacks, if
displaced stepping isn't supported, or register a different set of
callbacks if we wanted to support displaced stepping in those cases.
The commit that refactored the displaced stepping machinery and
introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
("gdb: move displaced stepping logic to gdbarch, allow starting
concurrent displaced steps"). However, even before that,
s390_gdbarch_init did:
set_gdbarch_displaced_step_location (gdbarch,
linux_displaced_step_location);
... which already seemed wrong. The Linux-specific callback was used
even for non-Linux system. Maybe that was on purpose, because it would
also happen to work in some other non-Linux case, or maybe it was simply
a mistake. I'll assume that this was a small mistake when
s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
("s390: Split up s390-linux-tdep.c into two files").
Fix this by removing the setting of these displaced step callbacks from
s390_gdbarch_init. Instead, pass num_disp_step_buffers=1 to
linux_init_abi, in s390_linux_init_abi_any. Doing so will cause
linux_init_abi to register these same callbacks. It will also mean that
when debugging a bare-metal s390 executable or an executable on another
OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
set, so displaced stepping won't be used.
This patch will need to be merged in the gdb-11-branch, since this is a
GDB 11 regression, so here's the ChangeLog entry:
gdb/ChangeLog:
* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
of displaced stepping buffers to linux_init_abi.
* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
displaced-stepping gdbarch callbacks.
Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1934505
Title:
gdb 11 doesn't work on impish/s390x: internal-error:
displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*,
thread_info*, CORE_ADDR&): Assertion
`gdbarch_data->num_disp_step_buffers > 0' failed.
Status in gdb:
Confirmed
Status in gdb package in Ubuntu:
Fix Released
Bug description:
gdb doesn't work on impish/s390x at the minute. Even if you say 'no'
to both questions you still can't debug:
ubuntu@laney-bos01-s390x-2:~/glib-networking-2.66.0/build$ gdb ls
GNU gdb (Ubuntu 11.0.50.20210630-0ubuntu1) 11.0.50.20210630-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "s390x-lin
[Touch-packages] [Bug 1934505]
The master branch has been updated by Simon Marchi
:
https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=74b10a3219e44ba2585e3f7226a6455d41e92c1b
commit 74b10a3219e44ba2585e3f7226a6455d41e92c1b
Author: Simon Marchi
Date: Wed Jul 7 08:57:36 2021 -0400
gdb: don't set Linux-specific displaced stepping methods in
s390_gdbarch_init
According to bug 28056, running an s390x binary gives:
(gdb) run
Starting program: /usr/bin/ls
/home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550:
internal-error: displaced_step_prepare_status
linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion
`gdbarch_data->num_disp_step_buffers > 0' failed.
This is because the s390 architecture registers some Linux-specific
displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:
set_gdbarch_displaced_step_prepare (gdbarch,
linux_displaced_step_prepare);
set_gdbarch_displaced_step_finish (gdbarch,
linux_displaced_step_finish);
set_gdbarch_displaced_step_restore_all_in_ptid
(gdbarch, linux_displaced_step_restore_all_in_ptid);
But then the Linux-specific s390_linux_init_abi_any passes
num_disp_step_buffers=0 to linux_init_abi:
linux_init_abi (info, gdbarch, 0);
The problem happens when linux_displaced_step_prepare is called for the
first time. It tries to allocate the displaced stepping buffers, but
sees that the number of displaced stepping buffers for that architecture
is 0, which is unexpected / invalid.
s390_gdbarch_init should not register the linux_* callbacks, that is
expected to be done by linux_init_abi. If debugging a bare-metal s390
program, or an s390 program on another OS GDB doesn't know about, we
wouldn't want to use them. We would either register no callbacks, if
displaced stepping isn't supported, or register a different set of
callbacks if we wanted to support displaced stepping in those cases.
The commit that refactored the displaced stepping machinery and
introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
("gdb: move displaced stepping logic to gdbarch, allow starting
concurrent displaced steps"). However, even before that,
s390_gdbarch_init did:
set_gdbarch_displaced_step_location (gdbarch,
linux_displaced_step_location);
... which already seemed wrong. The Linux-specific callback was used
even for non-Linux system. Maybe that was on purpose, because it would
also happen to work in some other non-Linux case, or maybe it was simply
a mistake. I'll assume that this was a small mistake when
s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
("s390: Split up s390-linux-tdep.c into two files").
Fix this by removing the setting of these displaced step callbacks from
s390_gdbarch_init. Instead, pass num_disp_step_buffers=1 to
linux_init_abi, in s390_linux_init_abi_any. Doing so will cause
linux_init_abi to register these same callbacks. It will also mean that
when debugging a bare-metal s390 executable or an executable on another
OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
set, so displaced stepping won't be used.
This patch will need to be merged in the gdb-11-branch, since this is a
GDB 11 regression, so here's the ChangeLog entry:
gdb/ChangeLog:
* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
of displaced stepping buffers to linux_init_abi.
* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
displaced-stepping gdbarch callbacks.
Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1934505
Title:
gdb 11 doesn't work on impish/s390x: internal-error:
displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*,
thread_info*, CORE_ADDR&): Assertion
`gdbarch_data->num_disp_step_buffers > 0' failed.
Status in gdb:
Confirmed
Status in gdb package in Ubuntu:
Fix Released
Bug description:
gdb doesn't work on impish/s390x at the minute. Even if you say 'no'
to both questions you still can't debug:
ubuntu@laney-bos01-s390x-2:~/glib-networking-2.66.0/build$ gdb ls
GNU gdb (Ubuntu 11.0.50.20210630-0ubuntu1) 11.0.50.20210630-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "s390x-linux-gnu"
[Touch-packages] [Bug 40214]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=364d77297723712a2952072fd6768601f17070bd commit 364d77297723712a2952072fd6768601f17070bd Author: Alan Modra Date: Thu Jun 3 18:32:30 2021 +0930 PR2589, ld vs. ld.so PR 2589 * ld.texi (link-time runtime library search path): Mention plugin library path. Correct order of search. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/40214 Title: ld checks for libs in wrong order. it should be inline with ld.so and check configured folders first. Status in binutils: Fix Released Status in binutils package in Ubuntu: Fix Released Bug description: if one installs a new version of a lib to /usr/local/lib and has an old version from the system in /usr/lib linking fails with gcc. it tries to link the version in /usr/lib removing the version from /usr/lib, linking works. ldd shows the right version in /usr/local/lib since the version of libtool in ubuntu does not include dependency_libs from the .la file, one has to specify the dependency libs manualy or remove the libs from /usr/lib; both merly workarounds that i dont want to use upstream. not sure what the right place for this bug is. To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/40214/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 697229]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=7ba115508aa02ffbb01a09613b5dffdd0c6563e3 commit 7ba115508aa02ffbb01a09613b5dffdd0c6563e3 Author: Alan Modra Date: Tue Sep 8 13:02:31 2020 +0930 PR26580, Size and alignment of commons vs as-needed shared lib Two pieces to this puzzle: 1) Revert HJ's fix for PR13250 so that size and alignment isn't sticky, instead attack the real underlying problem that _bfd_generic_link_add_one_symbol does the wrong thing in making a common section in a shared library bfd. 2) Save and restore common u.c.p fields, which hold the section and alignment. A better fix for (2) would be to throw away all of that horrible code saving and restoring the hash table when loading as-needed library symbols, and instead do a scan over as-needed library symbols before adding anything. bfd/ PR 13250 PR 26580 * elflink.c (_bfd_elf_merge_symbol): Make "override" a bfd**. Return oldbfd in override when old common should override new common. (_bfd_elf_add_default_symbol): Adjust to suit. (elf_link_add_object_symbols): Likewise. Pass "override" to _bfd_generic_link_add_one_symbol. Save and restore common u.c.p field for --as-needed shared libraries. Revert pr13250 changes. ld/ * testsuite/ld-elf/pr26580-a.s, * testsuite/ld-elf/pr26580-b.s, * testsuite/ld-elf/pr26580-1.sd, * testsuite/ld-elf/pr26580-2.sd: New tests * testsuite/ld-elf/comm-data.exp: Run new tests. * testsuite/ld-elf/pr26580-a.c, * testsuite/ld-elf/pr26580-b.c, * testsuite/ld-elf/pr26580-3.out, * testsuite/ld-elf/pr26580-4.out: New tests. * testsuite/ld-elf/shared.exp: Run new tests. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/697229 Title: openmpi link failure with ld --as-needed Status in binutils: Fix Released Status in binutils package in Ubuntu: Fix Released Status in openmpi package in Ubuntu: Invalid Status in binutils source package in Oneiric: Fix Released Status in openmpi source package in Oneiric: Invalid Status in binutils source package in Precise: Fix Released Status in openmpi source package in Precise: Invalid Status in openmpi package in Debian: Fix Released Bug description: $ cat test.F program main include 'mpif.h' integer ierr call mpi_init(ierr) end $ mpif90 test.F -Wl,--as-needed -Wall -Wno-unused-variable -g -I/usr/lib/openmpi/include -I/usr/lib/openmpi/lib -L/usr/lib/openmpi/lib -L/usr/lib/gcc/i686-linux-gnu/4.5.2 -ldl -lmpi -lopen-rte -lopen-pal -lnsl -lutil -lgcc_s -lpthread -ldl/usr/bin/ld: /tmp/cccq3IWF.o(.debug_info+0x48d): unresolvable R_X86_64_64 relocation against symbol `mpi_fortran_argv_null_' /usr/bin/ld: /tmp/cccq3IWF.o(.debug_info+0x4a7): unresolvable R_X86_64_64 relocation against symbol `mpi_fortran_argv_null_' /usr/bin/ld: /tmp/cccq3IWF.o(.debug_info+0x511): unresolvable R_X86_64_64 relocation against symbol `mpi_fortran_errcodes_ignore_' /usr/bin/ld: /tmp/cccq3IWF.o(.debug_info+0x52b): unresolvable R_X86_64_64 relocation against symbol `mpi_fortran_errcodes_ignore_' works with --no-as-needed. To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/697229/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1308261]
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ad09440a09597c34e0b93498aad9d6ef0b8ca9ae
commit r10-6121-gad09440a09597c34e0b93498aad9d6ef0b8ca9ae
Author: Jason Merrill
Date: Tue Jan 21 14:21:49 2020 -0500
PR c++/60855 - ICE with sizeof VLA capture.
For normal captures we usually look through them within unevaluated context,
but that doesn't work here; trying to take the sizeof of the array in the
enclosing scope tries and fails to evaluate a SAVE_EXPR from the enclosing
scope.
* lambda.c (is_lambda_ignored_entity): Don't look past VLA capture.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gcc-4.8 in Ubuntu.
https://bugs.launchpad.net/bugs/1308261
Title:
ICE provoked by a lambda using the sizeof a captured stack-allocated
array
Status in gcc:
Fix Released
Status in gcc-4.8 package in Ubuntu:
Confirmed
Status in gcc-4.9 package in Ubuntu:
Confirmed
Bug description:
See upstream report,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60855.
$ cat gcc-bug.cpp
int main() {
unsigned count = 5;
bool array[count];
[&array] () {
array[0] = sizeof(array) > 5;
}();
return 0;
}
$ g++ -Wall -Wextra --std=c++11 gcc-bug.cpp
gcc-bug.cpp: In lambda function:
gcc-bug.cpp:6:5: warning: ‘’ is used uninitialized in this
function [-Wuninitialized]
}();
^
gcc-bug.cpp:3:21: note: ‘’ was declared here
bool array[count];
^
gcc-bug.cpp:6:5: internal compiler error: in expand_expr_real_1, at
expr.c:9363
}();
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccVaDFxq.out file, please attach this to
your bugreport.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
$ lsb_release -rd
Description: Ubuntu 13.10
Release: 13.10
$ apt-cache policy gcc-4.8
gcc-4.8:
Installed: 4.8.1-10ubuntu9
Candidate: 4.8.1-10ubuntu9
Version table:
*** 4.8.1-10ubuntu9 0
500 http://us.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64
Packages
100 /var/lib/dpkg/status
4.8.1-10ubuntu8 0
500 http://us.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1308261/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479]
The master branch has been updated by Alan Modra
:
https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=0bc3450e220a4fb29f931ada84b546ce8993e85e
commit 0bc3450e220a4fb29f931ada84b546ce8993e85e
Author: Alan Modra
Date: Fri Dec 13 16:14:57 2019 +1030
Set no file contents PT_LOAD p_offset to first page
PR 25237
* elf.c (assign_file_positions_for_load_sections): Attempt to
keep meaningless p_offset for PT_LOAD segments without file
contents within file size.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479
Title:
gzip in Ubuntu Eoan results in Exec format error on WSL1
Status in binutils:
Confirmed
Status in binutils package in Ubuntu:
Fix Released
Status in gzip package in Ubuntu:
Fix Released
Status in binutils source package in Eoan:
Fix Committed
Status in gzip source package in Eoan:
Fix Committed
Bug description:
[Impact]
* Running gzip on WSL1 results in the following error:
$ gzip
-bash: /bin/gzip: cannot execute binary file: Exec format error
* The error occurs frequently in package updates and makes gzip inoperable
on WSL1
* The problem is caused by PT_LOAD offset pointing past the end of file and
the fix is fixing strip to not generate such ELF files and recompiling gzip
with the fixed strip.
[Test Case]
* Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v
size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
[ Regression Potential ]
* The binutils fix could cause binutils to generate invalid ELF files. The
fix is very small and isolated and has been tested and accepted by upstream,
which makes such problems unlikely.
* Bugs in the toolchain in general can make the rebuilt gzip show new
errors, but this generally applies to many SRUs and security updates. The
testing period in proposed should mitigate this risk.
[Originial Bug Text]
Summary:
Running gzip on WSL1 results in the following error:
$ gzip
-bash: /bin/gzip: cannot execute binary file: Exec format error
What I expect to happen:
gzip executes correctly on WSL1.
What happens instead:
gzip fails with an Exec format error.
Notes:
I suspect a change in how gzip is being built for Eoan is causing
issues with ELF parsing on the WSL1 translation layer. For example:
On Disco with gzip 1.9-3:
$ file /bin/gzip
/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped
On Eoan with gzip 1.10-0ubuntu3:
$ file /bin/gzip
/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0,
stripped
Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
not believe this is an issue in 1.10 because this error does not occur
when building gzip from GNU project source on Ubuntu Eoan.
Justifications:
WSL1 will need to be patched in future Windows builds for this change
in ELF. However that patch will likely not be backported to older
builds of Windows, including Windows Enterprise/Server 2019.
To ensure Eoan can run on current and older builds of Windows Ubuntu
should consider looking at how it's building gzip and see if it can be
made to 'play nice' until WSL1 can be updated.
This was originally reported here:
https://github.com/microsoft/WSL/issues/4461
Details:
Description:Ubuntu Eoan Ermine (development branch)
Release:19.10
gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
*** 1.10-0ubuntu3 500
500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1844119]
The binutils-2_33-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=a11b3493ca2d5aabdc218197b92026098d7e2f57 commit a11b3493ca2d5aabdc218197b92026098d7e2f57 Author: Alan Modra Date: Mon Sep 23 08:53:07 2019 +0930 PR25018, readelf crash on 32bits Pointer comparisons after adding an offset just don't work to catch overflow when the offset is a larger type than the pointer. PR 25018 * dwarf.c (get_type_signedness): Delete ineffective pointer comparison check. Properly range check uvalue offset on recursive call. (read_and_display_attr_value): Range check uvalue offset before calling get_type_signedness. (cherry picked from commit b3fe587ed2c78d46132bd33e14f42449d410354b) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1844119 Title: readelf crash on 32bit, leading to abi-monitor testsuite regression Status in binutils: Fix Released Status in binutils package in Ubuntu: Confirmed Status in glibc package in Ubuntu: Invalid Bug description: readelf --debug-dump=info libjsoncpp.so.1.8.1 to reproduce dpkg -l |grep binut ii binutils2.32.51.20190905-0ubuntu1 i386 GNU assembler, linker and binary utilities ii binutils-common:i3862.32.51.20190905-0ubuntu1 i386 Common files for the GNU assembler, linker and binary utilities ii binutils-i686-linux-gnu 2.32.51.20190905-0ubuntu1 i386 GNU binary utilities, for i686-linux-gnu target ii libbinutils:i3862.32.51.20190905-0ubuntu1 i386 GNU binary utilities (private shared library) To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1844119/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1845190]
The binutils-2_33-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=895b6d98785ba89819820aa5f4abed17fbb28c37 commit 895b6d98785ba89819820aa5f4abed17fbb28c37 Author: Alan Modra Date: Tue Sep 24 22:47:13 2019 +0930 PR25031, nm reports wrong address on 32bit Using saved_format breaks when nm is presented with multiple object files, some 32-bit and some 64-bit. PR 25031 * nm.c (print_format_string): New. (get_print_format): Delete saved_format. Move earlier. (set_print_width): Call get_print_format. (print_value): Use print_format_string. (cherry picked from commit 352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1845190 Title: binutils nm wrong output format breaks i386 nm work Status in binutils: In Progress Status in binutils package in Ubuntu: Confirmed Bug description: discovered with diffoscope autopkgregression, looks like a real bug, based on https://salsa.debian.org/reproducible-builds/diffoscope/issues/69 To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1845190/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1845190]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd commit 352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd Author: Alan Modra Date: Tue Sep 24 22:47:13 2019 +0930 PR25031, nm reports wrong address on 32bit Using saved_format breaks when nm is presented with multiple object files, some 32-bit and some 64-bit. PR 25031 * nm.c (print_format_string): New. (get_print_format): Delete saved_format. Move earlier. (set_print_width): Call get_print_format. (print_value): Use print_format_string. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1845190 Title: binutils nm wrong output format breaks i386 nm work Status in binutils: In Progress Status in binutils package in Ubuntu: Confirmed Bug description: discovered with diffoscope autopkgregression, looks like a real bug, based on https://salsa.debian.org/reproducible-builds/diffoscope/issues/69 To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1845190/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1844119]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=b3fe587ed2c78d46132bd33e14f42449d410354b commit b3fe587ed2c78d46132bd33e14f42449d410354b Author: Alan Modra Date: Mon Sep 23 08:53:07 2019 +0930 PR25018, readelf crash on 32bits Pointer comparisons after adding an offset just don't work to catch overflow when the offset is a larger type than the pointer. PR 25018 * dwarf.c (get_type_signedness): Delete ineffective pointer comparison check. Properly range check uvalue offset on recursive call. (read_and_display_attr_value): Range check uvalue offset before calling get_type_signedness. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1844119 Title: readelf crash on 32bit, leading to abi-monitor testsuite regression Status in binutils: Fix Released Status in binutils package in Ubuntu: Confirmed Status in glibc package in Ubuntu: Invalid Bug description: readelf --debug-dump=info libjsoncpp.so.1.8.1 to reproduce dpkg -l |grep binut ii binutils2.32.51.20190905-0ubuntu1 i386 GNU assembler, linker and binary utilities ii binutils-common:i3862.32.51.20190905-0ubuntu1 i386 Common files for the GNU assembler, linker and binary utilities ii binutils-i686-linux-gnu 2.32.51.20190905-0ubuntu1 i386 GNU binary utilities, for i686-linux-gnu target ii libbinutils:i3862.32.51.20190905-0ubuntu1 i386 GNU binary utilities (private shared library) To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1844119/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1833237]
The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=bb22a41815facfaa3de621aad5d055eb8e477082 commit bb22a41815facfaa3de621aad5d055eb8e477082 Author: Alan Modra Date: Sun Jun 23 12:28:39 2019 +0930 PR24704, Internal error building skiboot for powerpc64-linux-gnu While the skiboot linker script bears some culpability in this PR, it's also true that the GOT indirect to GOT relative optimisation for 16-bit offsets isn't safe. At least, it isn't safe to remove the GOT entry based on distance between the GOT pointer and symbol calculated from the preliminary layout. So this patch removes that optimisation, and reduces the range allowed for 32-bit and 34-bit offsets. PR 24704 bfd/ * elf64-ppc.c (R_PPC64_GOT16_DS): Don't set has_gotrel. (ppc64_elf_edit_toc): Don't remove R_PPC64_GOT16_DS got entries. Reduce range of offsets allowed for other GOT relocs. ld/ * testsuite/ld-powerpc/elfv2exe.d: Update. * testsuite/ld-powerpc/elfv2so.d: Update. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1833237 Title: skiboot ftbfs in eoan Status in binutils: In Progress Status in binutils package in Ubuntu: Confirmed Status in skiboot package in Ubuntu: Confirmed Status in binutils source package in Eoan: Confirmed Status in skiboot source package in Eoan: Confirmed Bug description: skiboot ftbfs in eoan https://launchpad.net/ubuntu/+archive/test- rebuild-20190614/+build/17038512/+files/buildlog_ubuntu-eoan- amd64.skiboot_6.2-1_BUILDING.txt.gz powerpc64-linux-gnu-gcc-I/<>/include -Iinclude -MMD -include /<>/include/config.h -I/<>/libfdt -I/<>/libflash -I/<>/libxz -I/<>/libc/include -I/<> -I/<>/libpore -D__SKIBOOT__ -nostdinc -isystem /usr/lib/gcc-cross/powerpc64-linux-gnu/8/include -DBITS_PER_LONG=64 -DHAVE_BIG_ENDIAN -ffreestanding -DHAS_STACK_PROT -D__ASSEMBLY__ -mbig-endian -m64 -mabi=elfv1 -c asm/dummy_map.S -o asm/dummy_map.o powerpc64-linux-gnu-gcc -I/<>/include -Iinclude -MMD -include /<>/include/config.h -I/<>/libfdt -I/<>/libflash -I/<>/libxz -I/<>/libc/include -I/<> -I/<>/libpore -D__SKIBOOT__ -nostdinc -isystem /usr/lib/gcc-cross/powerpc64-linux-gnu/8/include -DBITS_PER_LONG=64 -DHAVE_BIG_ENDIAN -ffreestanding -DHAS_STACK_PROT -P -E skiboot.lds.S -o skiboot.lds powerpc64-linux-gnu-ld -EB -m elf64ppc --no-multi-toc -N --build-id=none --whole-archive -static -nostdlib -pie -Ttext-segment=0x0 --oformat=elf64-powerpc -o skiboot.tmp.elf -T skiboot.lds skiboot.tmp.a asm/dummy_map.o powerpc64-linux-gnu-ld: BFD (GNU Binutils for Ubuntu) 2.32.51.20190614 internal error, aborting at ../../bfd/elf64-ppc.c:15381 in ppc64_elf_relocate_section powerpc64-linux-gnu-ld: Please report this bug. make[2]: *** [/<>/Makefile.main:262: skiboot.tmp.elf] Error 1 make[2]: Leaving directory '/<>' make[1]: *** [debian/rules:19: override_dh_auto_build-indep] Error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1833237/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 420609]
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The annotated tag, glibc-2.29 has been created at e7c9e41bb2407b0150997b382b49a5f3bb579bf9 (tag) tagging 56c86f5dd516284558e106d04b92875d5b623b7a (commit) replaces glibc-2.28.9000 tagged by Siddhesh Poyarekar on Thu Jan 31 22:24:07 2019 +0530 - Log - The GNU C Library = The GNU C Library version 2.29 is now available. The GNU C Library is used as *the* C library in the GNU system and in GNU/Linux systems, as well as many other systems that use Linux as the kernel. The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C11 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known. The GNU C Library webpage is at http://www.gnu.org/software/libc/ Packages for the 2.29 release may be downloaded from: http://ftpmirror.gnu.org/libc/ http://ftp.gnu.org/gnu/libc/ The mirror list is at http://www.gnu.org/order/ftp.html NEWS for version 2.29 * The getcpu wrapper function has been added, which returns the currently used CPU and NUMA node. This function is Linux-specific. * A new convenience target has been added for distribution maintainers to build and install all locales as directories with files. The new target is run by issuing the following command in your build tree: 'make localedata/install-locale-files', with an optional DESTDIR to set the install root if you wish to install into a non-default configured location. * Optimized generic exp, exp2, log, log2, pow, sinf, cosf, sincosf and tanf. * The reallocarray function is now declared under _DEFAULT_SOURCE, not just for _GNU_SOURCE, to match BSD environments. * For powercp64le ABI, Transactional Lock Elision is now enabled iff kernel indicates that it will abort the transaction prior to entering the kernel (PPC_FEATURE2_HTM_NOSC on hwcap2). On older kernels the transaction is suspended, and this caused some undefined side-effects issues by aborting transactions manually. Glibc avoided it by abort transactions manually on each syscall, but it lead to performance issues on newer kernels where the HTM state is saved and restore lazily (the state being saved even when the process actually does not use HTM). * The functions posix_spawn_file_actions_addchdir_np and posix_spawn_file_actions_addfchdir_np have been added, enabling posix_spawn and posix_spawnp to run the new process in a different directory. These functions are GNU extensions. The function posix_spawn_file_actions_addchdir_np is similar to the Solaris function of the same name. * The popen and system do not run atfork handlers anymore (BZ#17490). Although it is a possible POSIX violation, the POSIX rationale in pthread_atfork documentation regarding atfork handlers is to handle inconsistent mutex state after a fork call in a multi-threaded process. In both popen and system there is no direct access to user-defined mutexes. * Support for the C-SKY ABIV2 running on Linux has been added. This port requires at least binutils-2.32, gcc-9.0, and linux-4.20. Two ABIs are supported: - C-SKY ABIV2 soft-float little-endian - C-SKY ABIV2 hard-float little-endian * strftime's default formatting of a locale's alternative year (%Ey) has been changed to zero-pad the year to a minimum of two digits, like "%y". This improves the display of Japanese era years during the first nine years of a new era, and is expected to be harmless for all other locales (only Japanese locales regularly have alternative year numbers less than 10). Zero-padding can be overridden with the '_' or '-' flags (which are GNU extensions). * As a GNU extension, the '_' and '-' flags can now be applied to "%EY" to control how the year number is formatted; they have the same effect that they would on "%Ey". Deprecated and removed features, and other changes affecting compatibility: * The glibc.tune tunable namespace has been renamed to glibc.cpu and the tunable glibc.tune.cpu has been renamed to glibc.cpu.name. * The type of the pr_uid and pr_gid members of struct elf_prpsinfo, defined in , has been corrected to match the type actually used by the Linux kernel. This affects the size and layout of that structure on MicroBlaze, MIPS (n64 ABI only), Nios II and RISC-V. * For the MIPS n32 ABI, the type of the pr_sigpend and pr_sighold members of struct elf_prstatus, and the pr_flag member of struct elf_prpsinfo, defined in , has been corrected to match the type actually used by the Linux kernel. This affects the size and layout of those structures. * An archaic G
[Touch-packages] [Bug 420609]
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 434d45fd70ac1a137d01b715ea99c03ce3c21b14 (commit) from 7abf97bed9c24464a8a68fb9f9fe8d1e55c6b54c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=434d45fd70ac1a137d01b715ea99c03ce3c21b14 commit 434d45fd70ac1a137d01b715ea99c03ce3c21b14 Author: Rafal Luzynski Date: Fri Sep 14 22:43:02 2018 +0200 it_CH/it_IT locales: Correct some LC_TIME formats (bug 10425). Synchronize some values with CLDR and apply some suggestions from Bugzilla. [BZ #10425] * localedata/locales/it_IT (d_t_fmt): Use "%a %-d %b %Y, %T". (date_fmt): Use "%a %-d %b %Y, %T, %Z". * localedata/locales/it_CH (d_t_fmt): Use "%a %-d %b %Y, %T" which is the same as in it_IT. (d_fmt): Use "%d.%m.%Y" which is the same as in de_CH. (date_fmt): Use "%a %-d %b %Y, %T, %Z" which is the same as in it_IT. --- Summary of changes: ChangeLog| 10 ++ localedata/locales/it_CH |6 +++--- localedata/locales/it_IT |4 ++-- 3 files changed, 15 insertions(+), 5 deletions(-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to eglibc in Ubuntu. https://bugs.launchpad.net/bugs/420609 Title: wrong LC_TIME in Italian Status in GLibC: Fix Released Status in eglibc package in Ubuntu: Fix Released Status in glibc package in Ubuntu: Invalid Bug description: Accordingly to this file [1], this newspaper [2], and also because I'm Italian, there is an error in the way the date is displayed in linux. The correct format for Italian speakers is: day_name day_number month_name year, HH:MM:SS, time_zone in the LC_TIME date_fmt things are really mixed up and should be changed to: %a %e %b %Y, %H:%M:%S, %Z the file localedata/locales/it_IT needs to be changed, but I can't understand how, since there are only strange codes [1]: ftp://ftp.software.ibm.com/software/globalization/locales/Italy-Italian_Date.pdf [2]: http://www.corriere.it/ To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/420609/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
