RE: ILP32 toolchain status update
Note gdb patches are located at: https://sourceware.org/ml/binutils/2017-03/msg00075.html https://sourceware.org/ml/gdb-patches/2017-03/msg00051.html >2. [GLIBC] LP64 glibc libthread_db does not support ILP32. No change to glibc was needed to fix this, only the above changes to gdb were needed. >3. [GDB] Handle ILP32 siginfo layout The change to aarch64_linux_siginfo_fixup fixes that. >4. [GDB] Inferior call passing pointer argument. The change to aarch64_gdbarch_init fixes that. >5. Handle shared libraries The change to aarch64_linux_init_abi fixes that. >6. [GDB] GDB resolves ifunc functions, The change to aarch64_gdbarch_init fixes that IIRC. >7. [GDB] Gdbserver support for ILP32. The change to aarch64_linux_read_description fixes that. Thanks, Andrew -Original Message- From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf Of Maxim Kuvyrkov Sent: Tuesday, November 7, 2017 4:40 AM To: Linaro Toolchain Cc: Szabolcs Nagy ; Ellcey, Steve Subject: ILP32 toolchain status update Over the last couple of months arm64 community and us have tested various aspects of ILP32 toolchain and, while most of toolchain works as expected, several features are still missing. Most of the work left is on GDB side, especially using LP64 GDB to debug ILP32 applications. 1. [GCC] GCC sanitizers (ASAN, UBSAN) are not supported for ILP32. -- TCWG is working on implementing sanitizer support for ILP32. 2. [GLIBC] LP64 glibc libthread_db does not support ILP32. This causes failures when LP64 GDB is trying to debug ILP32 threaded application. It is expected by users to be able to use LP64 GDB to debug ILP32 applications (LP64 AArch64 GDB can successfully debug AArch32 applications already!). -- Steve, do you plan to work on adding libthread_db support for ILP32? 3. [GDB] Handle ILP32 siginfo layout. Kernel siginfo layout is different between LP64 and ILP32. 4. [GDB] Inferior call passing pointer argument. GDB may need update to handle 32-bit pointer vs 64-bit pointer. 5. Handle shared libraries. GDB needs to read a linked list out of the inferior, and that list is about the libraries loaded already. LP64 and ILP32 may have different layouts. 6. [GDB] GDB resolves ifunc functions, needs to read auxv (HWCAP) from the inferior. auxv is different on LP64 and ILP32. 7. [GDB] Gdbserver support for ILP32. -- Maxim Kuvyrkov www.linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[FYI] HCQC(HPC compiler quality checker) on GitHub
Hi, I put HCQC(HPC compiler quality checker) on GitHub. URL: https://github.com/Linaro/hcqc Any comments or suggestions are very welcome. I am going to improve README.md overall and to add more test programs. I will also report the analysis results using HCQC on hpc-sig-devel. The attached PDF file was used to explain HCQC at HPC-SIG SC meeting(11/7). I think you can reproduce the results on this slide if you modify the following part of the configuration file: hcqc/config/clang-config.json "COMMAND" : "/usr/bin/clang", "VERSION" : "4.0.1", hcqc/config/gcc-config.json "COMMAND" : "/usr/bin/gcc-7", "VERSION" : "7.1.1", which you need to fix to suit your environment. [image: https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] Best regards, -- -- Masaki Arai ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: ILP32 toolchain status update
On 7 November 2017 at 13:35, Pinski, Andrew wrote:
> Note gdb patches are located at:
> https://sourceware.org/ml/binutils/2017-03/msg00075.html
> https://sourceware.org/ml/gdb-patches/2017-03/msg00051.html
>
>
All these TODOs are given based on the observations of gdb tests result
with these two patches above applied.
>>2. [GLIBC] LP64 glibc libthread_db does not support ILP32.
> No change to glibc was needed to fix this, only the above changes to gdb were
> needed.
>
There are still some failed tests in gdb.threads/,
FAIL: gdb.threads/thread-specific-bp.exp: all-stop: get main thread id
FAIL: gdb.threads/thread-specific-bp.exp: non-stop: get main thread id
FAIL: gdb.threads/thread-specific.exp: get threads list (no threads)
>>3. [GDB] Handle ILP32 siginfo layout
>
> The change to aarch64_linux_siginfo_fixup fixes that.
>
FAIL: gdb.base/siginfo-obj.exp: p ssi_addr
FAIL: gdb.base/siginfo-obj.exp: p ssi_addr
FAIL: gdb.base/siginfo-obj.exp: p
$_siginfo._sifields._sigfault.si_addr from core file
FAIL: gdb.base/siginfo-thread.exp: p ssi_addr
FAIL: gdb.base/siginfo-thread.exp: p
$_siginfo._sifields._sigfault.si_addr from core file
>>4. [GDB] Inferior call passing pointer argument.
>
> The change to aarch64_gdbarch_init fixes that.
>
FAIL: gdb.base/callfuncs.exp: p t_string_values("string 1","string 2")
FAIL: gdb.base/callfuncs.exp: p t_string_values("string 1",string_val2)
FAIL: gdb.base/callfuncs.exp: p t_string_values(string_val1,"string 2")
FAIL: gdb.base/callfuncs.exp: p t_char_array_values("carray 1","carray 2")
FAIL: gdb.base/callfuncs.exp: p t_char_array_values("carray 1",char_array_val2)
FAIL: gdb.base/callfuncs.exp: p t_char_array_values(char_array_val1,"carray 2")
FAIL: gdb.base/callfuncs.exp: p sum_args(1,{2})
FAIL: gdb.base/callfuncs.exp: p sum_args(2,{2,3})
FAIL: gdb.base/callfuncs.exp: p sum_args(3,{2,3,4})
FAIL: gdb.base/callfuncs.exp: p sum_args(4,{2,3,4,5})
FAIL: gdb.base/callfuncs.exp: noproto: p t_string_values("string 1","string 2")
FAIL: gdb.base/callfuncs.exp: noproto: p t_string_values("string 1",string_val2)
FAIL: gdb.base/callfuncs.exp: noproto: p t_string_values(string_val1,"string 2")
FAIL: gdb.base/callfuncs.exp: noproto: p t_char_array_values("carray
1","carray 2")
FAIL: gdb.base/callfuncs.exp: noproto: p t_char_array_values("carray
1",char_array_val2)
FAIL: gdb.base/callfuncs.exp: noproto: p
t_char_array_values(char_array_val1,"carray 2")
FAIL: gdb.base/callfuncs.exp: noproto: p sum_args(1,{2})
FAIL: gdb.base/callfuncs.exp: noproto: p sum_args(2,{2,3})
FAIL: gdb.base/callfuncs.exp: noproto: p sum_args(3,{2,3,4})
FAIL: gdb.base/callfuncs.exp: noproto: p sum_args(4,{2,3,4,5})
>>5. Handle shared libraries
>
> The change to aarch64_linux_init_abi fixes that.
>
There are still many failed tests about shared library.
FAIL: gdb.base/catch-load.exp: plain load with stop-on-solib-events:
set var libname = "catch-load-so.so"
FAIL: gdb.base/catch-load.exp: plain load with stop-on-solib-events: continue
FAIL: gdb.base/catch-load.exp: rx load with stop-on-solib-events: set
var libname = "catch-load-so.so"
FAIL: gdb.base/catch-load.exp: rx load with stop-on-solib-events: continue
FAIL: gdb.base/catch-load.exp: non-matching load with
stop-on-solib-events: set var libname = "catch-load-so.so"
FAIL: gdb.base/catch-load.exp: non-matching load with
stop-on-solib-events: continue
FAIL: gdb.base/catch-load.exp: plain unload with stop-on-solib-events:
set var libname = "catch-load-so.so"
FAIL: gdb.base/catch-load.exp: plain unload with stop-on-solib-events: continue
FAIL: gdb.base/catch-load.exp: rx unload with stop-on-solib-events:
set var libname = "catch-load-so.so"
FAIL: gdb.base/catch-load.exp: rx unload with stop-on-solib-events: continue
FAIL: gdb.base/catch-load.exp: non-matching unload with
stop-on-solib-events: set var libname = "catch-load-so.so"
FAIL: gdb.base/catch-load.exp: non-matching unload with
stop-on-solib-events: continue
FAIL: gdb.base/skip-solib.exp: step after ignoring solib file.
FAIL: gdb.base/skip-solib.exp: step (the program exited)
FAIL: gdb.base/skip-solib.exp: bt
FAIL: gdb.base/so-impl-ld.exp: step into solib call
FAIL: gdb.base/so-impl-ld.exp: step in solib call
FAIL: gdb.base/so-impl-ld.exp: step out of solib call
FAIL: gdb.base/solib-display.exp: NO: display (int) a_global
FAIL: gdb.base/solib-display.exp: NO: display (int) b_global
FAIL: gdb.base/solib-display.exp: NO: display (int) c_global
FAIL: gdb.base/solib-display.exp: NO: after rerun
FAIL: gdb.base/solib-display.exp: NO: after rerun (2)
FAIL: gdb.base/solib-display.exp: NO: display main_global
FAIL: gdb.base/solib-display.exp: NO: display a_local
FAIL: gdb.base/solib-display.exp: NO: display a_static
FAIL: gdb.base/solib-display.exp: NO: continue
FAIL: gdb.base/solib-display.exp: IN: display (int) a_global
FAIL: gdb.base/solib-display.exp: IN: display (int) b_global
FAIL: gdb.base/solib-display.exp: IN: display (int) c_global
FAIL: gdb.base/solib-display.exp: IN: after rerun
FAIL: gdb.base/solib-dis
[ANNOUNCE] Linaro Binary Toolchain Release-Candidate GCC 6.4-2017.11-rc1
The Linaro Binary Toolchain The Linaro GCC 6.4-2017.11-rc1 Release-Candidate is now available. The GCC 6 Release series has significant changes from the GCC 5 release series. For an explanation of the changes please see the following website: https://gcc.gnu.org/gcc-6/changes.html For help in porting to GCC 6 please see the following explanation: https://gcc.gnu.org/gcc-6/porting_to.html Download release-candidate packages from: (sources) http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.4-2017.11-rc1/ (binaries) http://snapshots.linaro.org/components/toolchain/binaries/6.4-2017.11-rc1/ Previous snapshots and release-candidates are at: http://snapshots.linaro.org/components/toolchain/binaries/ Previous releases are at: http://releases.linaro.org/components/toolchain/binaries/ A description of the arm and AArch64 target triples can be found at: https://collaborate.linaro.org/display/TCWGPUB/ARM+and+AArch64+Target+Triples Host Requirements == Linaro officially supports the current and previous Ubuntu LTS releases (as of the time of this release). This does not mean that the toolchain will not work on other/older Linux distributions. See the following for the life-time of Ubuntu LTS releases. https://wiki.ubuntu.com/Releases The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc's memcpy API. https://bugs.linaro.org/show_bug.cgi?id=1869 Package Versions = Linaro GCC 6.4-2017.11-rc1 http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.4-2017.11-rc1/ Linaro glibc 2.23 (linaro/2.23/master) https://lists.gnu.org/archive/html/info-gnu/2016-02/msg9.html Linaro newlib 2.4-2016.03 (linaro_2.4-branch) https://sourceware.org/ml/newlib/2016/msg00370.html Linaro binutils 2.27 (linaro-local/linaro_binutils-2_27-branch) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_27 Linaro GDB 8.0 (gdb-8.0-branch) https://lists.gnu.org/archive/html/info-gnu/2016-10/msg7.html Linaro toolchain package git branches are hosted at: http://git.linaro.org/toolchain NEWS for GCC 6 (as of Linaro GCC 6.4-2017.11-rc1) == * Previous MinGW hosted version of Linaro GCC C preprocessor failed to convert character set used for string, character constants, etc. This is fixed in this release. Linaro bugzilla #3040 : CC1 and cc1plus cannot convert UTF-8. https://bugs.linaro.org/show_bug.cgi?id=3040 * The Linaro GCC 6.3-2017.05 snapshot added support for -mpure-code option to ARMv7-M and ARMv8-M targets. This option ensures functions are put into sections that contain only code and no data. * The GDB version was upgraded from GDB 8.0. * Previous versions of the Linaro GCC 6 toolchain, when -static -E/—dynamic-list are passed to the linker, might create executables with dynamic sections which aren’t supported by run-time. This was exhibited in Perf Tools build system and has been fixed upstream and backported into Linaro Binutils 2.27 branch. Linaro bugzilla #2926 : Perf tools compiled statically for AArch64 with Linaro release 6.1 and later ones was not statically linked. https://bugs.linaro.org/show_bug.cgi?id=2926 * The Linaro GCC 6.3-2017.03 snapshot fixed some ILP32 issues (TLS, exception handling, …) and these have been incorporated into this release. * Previous versions of the Linaro GCC 6 toolchain were incorrectly generating floating-point code for soft-float Linux targets (arm-linux-gnueabi, and armeb-linux-gnueabi). This escaped detection until recently because the soft-float targeted toolchains were configured to use general-purpose registers for passing floating-point values (which is what you would expect for soft-float toolchains) and the intra-routine floating-code was not noticed. The issue would only show up on targets that were run on hardware that truly didn't have floating-point hardware where the kernel did not trap and emulate floating-point routines. This has been solved in Linaro GCC 6.3-2017.02-rc2 by configuring the toolchain (using --with-float=soft) to generate code without any floating-point instructions at all (-mfloat-abi=soft). https://review.linaro.org/#/c/16968/2 This change should not break compatibility between existing binaries compiled with these toolchains since the float-point parameter passing ABI is still the same. * A bug/regression in the compiler has been identified whereby the target function that is invoked when calling a "weak" function directly is the "strong" override, whereas when calling the function via a pointer the "weak" implementation is used. This would be noticed as inconsistent funct
[ANNOUNCE] Linaro Binary Toolchain Release-Candidate GCC 7.2-2017.11-rc1
The Linaro Binary Toolchain The Linaro GCC 7.2-2017.11-rc1 Release-Candidate is now available. *Notice*: GCC 7.1 ABI change for arm*-*-* targets, and note for aarch64*-*-* targets From GCC 7.1 release notes: On ARM targets (arm*-*-*), a bug introduced in GCC 5 that affects conformance to the procedure call standard (AAPCS) has been fixed. The bug affects some C++ code where class objects are passed by value to functions and could result in incorrect or inconsistent code being generated. This is an ABI change. If the option -Wpsabi is enabled (on by default) the compiler will emit a diagnostic note for code that might be affected. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 GCC 5 and GCC 6 releases will continue to be affected by the ABI bug, since changing ABI in these releases is not practical. A warning enabled by -Wpsabi option was added to GCC 5 and GCC 6 toolchains to diagnose codebases that might be affected by the ABI bug. Additionally, this same bug was present in AArch64 backend in development versions of GCC 7. There was no releases of GCC with this bug present in AArch64 backend, therefore the release notes does not mention this. However, be advised that any code bases built with development versions of GCC 7 need to be recompiled with released version of GCC 7 to conform to ABI. For an explanation of GCC 7 series changes please see the following website: https://gcc.gnu.org/gcc-7/changes.html For help in porting to GCC 7 please see the following explanation: https://gcc.gnu.org/gcc-7/porting_to.html Download release-candidate packages from: (sources) http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.11-rc1/ (binaries) http://snapshots.linaro.org/components/toolchain/binaries/7.2-2017.11-rc1/ Previous snapshots and release-candidates are at: http://snapshots.linaro.org/components/toolchain/binaries/ Previous releases are at: http://releases.linaro.org/components/toolchain/binaries/ A description of the arm and AArch64 target triples can be found at: https://collaborate.linaro.org/display/TCWGPUB/ARM+and+AArch64+Target+Triples Host Requirements == Linaro officially supports the current and previous Ubuntu LTS releases (as of the time of this release). This does not mean that the toolchain will not work on other/older Linux distributions. See the following for the life-time of Ubuntu LTS releases. https://wiki.ubuntu.com/Releases The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc's memcpy API. https://bugs.linaro.org/show_bug.cgi?id=1869 Package Versions = Linaro GCC 7.2-2017.11-rc1 http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.11-rc1/ FSF glibc 2.25 (release/2.25) https://lists.gnu.org/archive/html/info-gnu/2017-02/msg2.html Newlib 2.5 (newlib-2_5_0 tag) https://sourceware.org/ml/newlib/2016/msg01191.html GNU Binutils 2.28 (linaro-local/linaro_binutils-2_28-branch) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_28 FSF GDB 8.0 (gdb-8.0-branch) https://sourceware.org/ml/gdb-announce/2017/msg3.html Linaro toolchain package git branches are hosted at: http://git.linaro.org/toolchain NEWS for GCC 7 (as of Linaro GCC 7.2-2017.11-rc1) == * The Linaro GCC 7.2-2017.09 snapshot added float and integer moves improvement for AArch64 targets. * The Linaro GCC 7.1-2017.07 snapshot added prefetching configuration improvement for AArch64 targets and laid groundwork to enabling prefetching in more cases. * Previous MinGW hosted version of Linaro GCC C preprocessor failed to convert character set used for string, character constants, etc. This is fixed in this release. Linaro bugzilla #3040 : CC1 and cc1plus cannot convert UTF-8. https://bugs.linaro.org/show_bug.cgi?id=3040 * Performance related backports from the following snapshots have been included: Linaro GCC 7.1-2017.05, Linaro GCC 7.1-2017.06, Linaro GCC 7.1-2017.07, Linaro GCC 7.2-2017.08, Linaro GCC 7.2-2017.09 and Linaro GCC 7.2-2017.10. See the following Linaro GCC snapshots: http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.1-2017.05/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.1-2017.06/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.1-2017.07/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.08/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.09/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.10/ Contact Linaro === File bugs at http://bugs.linaro.org For Linaro member support see http://support.lin
Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
Hi Masaki, On 8 November 2017 at 04:38, Masaki Arai wrote: > Hi, > > I put HCQC(HPC compiler quality checker) on GitHub. > > URL: https://github.com/Linaro/hcqc > > Any comments or suggestions are very welcome. > I am going to improve README.md overall and to add more test programs. > I will also report the analysis results using HCQC on hpc-sig-devel. > > The attached PDF file was used to explain HCQC at HPC-SIG SC meeting(11/7). > I think you can reproduce the results on this slide if you modify the > following part of the configuration file: it seems that this PDF is missing. Best regards, Yvan > hcqc/config/clang-config.json > "COMMAND" : "/usr/bin/clang", > "VERSION" : "4.0.1", > > hcqc/config/gcc-config.json > "COMMAND" : "/usr/bin/gcc-7", > "VERSION" : "7.1.1", > > which you need to fix to suit your environment. > > [image: https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] > > > > > Best regards, > -- > -- > Masaki Arai > ___ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [hpc-sig-devel] Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
On 8 November 2017 at 17:19, Masaki Arai wrote: > Hi, > > I am sorry for the inconvenience. > > #I'm not sure what is going on. > #I can extract PDF from my first e-mail.!? I could see the PDF on the first email, and on this one too. :) --renato ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
FTR, i don't see any attached PDF's in this e-mail either. On 11/08/2017 12:18 PM, Yvan Roux wrote: Hi Masaki, On 8 November 2017 at 04:38, Masaki Arai wrote: Hi, I put HCQC(HPC compiler quality checker) on GitHub. URL: https://github.com/Linaro/hcqc Any comments or suggestions are very welcome. I am going to improve README.md overall and to add more test programs. I will also report the analysis results using HCQC on hpc-sig-devel. The attached PDF file was used to explain HCQC at HPC-SIG SC meeting(11/7). I think you can reproduce the results on this slide if you modify the following part of the configuration file: it seems that this PDF is missing. Best regards, Yvan hcqc/config/clang-config.json "COMMAND" : "/usr/bin/clang", "VERSION" : "4.0.1", hcqc/config/gcc-config.json "COMMAND" : "/usr/bin/gcc-7", "VERSION" : "7.1.1", which you need to fix to suit your environment. [image: https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] Best regards, -- -- Masaki Arai ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [hpc-sig-devel] Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
On 8 November 2017 at 17:30, Luis Machado wrote: > FTR, i don't see any attached PDF's in this e-mail either. It's possible that the pdf went to hpc-sig-dev and not toolchain. maybe toolchain doesn't allow attachments? ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [hpc-sig-devel] Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
On 8 November 2017 at 18:25, Renato Golin wrote: > On 8 November 2017 at 17:19, Masaki Arai wrote: >> Hi, >> >> I am sorry for the inconvenience. >> >> #I'm not sure what is going on. >> #I can extract PDF from my first e-mail.!? > > > I could see the PDF on the first email, and on this one too. :) hmm, I still don't see it :( can it be some differences between hpc-sig-devel@ and linaro-toochain@ lists config ? Yvan ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [hpc-sig-devel] Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
On 8 November 2017 at 18:31, Renato Golin wrote: > On 8 November 2017 at 17:30, Luis Machado wrote: >> FTR, i don't see any attached PDF's in this e-mail either. > > It's possible that the pdf went to hpc-sig-dev and not toolchain. > maybe toolchain doesn't allow attachments? something like that I guess, but I can see at least one attachment (.tar file) among the last 1k emaisl on that list ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: ILP32 toolchain status update
On 8 November 2017 at 16:56, Pinski, Andrew wrote: > What env are you using? Are the glibc versions on the same between ILP32 and > LP64? Because when that was true I did not have any issues with libthread_db. > I didn't run gdb tests in ILP32 env, and I don't have such env. I got gdb.sum from Steve on 18 Oct. You are on the cc as well. All my analysis is based on that gdb.sum. > Anyways I did not see some of those failures listed below when using the > correct setup. OK, can you send me a gdb.sum? -- Yao Qi ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [hpc-sig-devel] Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
Hi, Thank you very much for your reply. I committed the PDF file on GitHub. Please download it from URL: https://github.com/Linaro/hcqc/blob/master/doc/hcqc-2017-11-07.pdf Best regards, -- -- Masaki Arai ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [hpc-sig-devel] Re: [FYI] HCQC(HPC compiler quality checker) on GitHub
On 8 November 2017 at 18:58, Masaki Arai wrote: > Hi, > > Thank you very much for your reply. > > I committed the PDF file on GitHub. > Please download it from >URL: https://github.com/Linaro/hcqc/blob/master/doc/hcqc-2017-11-07.pdf Thanks a lot Masaki. > Best regards, > > -- > -- > Masaki Arai > > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: ILP32 toolchain status update
On 08/11/2017 15:49, Yao Qi wrote: > On 8 November 2017 at 16:56, Pinski, Andrew wrote: >> What env are you using? Are the glibc versions on the same between ILP32 >> and LP64? Because when that was true I did not have any issues with >> libthread_db. >> > > I didn't run gdb tests in ILP32 env, and I don't have such env. I got > gdb.sum from Steve on 18 Oct. You are on the cc as well. All my analysis > is based on that gdb.sum. > >> Anyways I did not see some of those failures listed below when using the >> correct setup. > > OK, can you send me a gdb.sum? > Btw, any of you have a easy development ready ILP32 env? I have working IPL32 native kvm machine and I trying to bootstrap a devel environment using abe to check the sanitizers (a native one). ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: ILP32 toolchain status update
> On Nov 8, 2017, at 9:03 PM, Pinski, Andrew wrote: > > I thought the decision Linaro/Arm was going to take over the development of > the ILP32? > What happened to that decision? Hi Andrew, Where such a decision was discussed? -- Maxim Kuvyrkov www.linaro.org > > Thanks, > Andrew > > -Original Message- > From: Yao Qi [mailto:yao...@linaro.org] > Sent: Wednesday, November 8, 2017 9:50 AM > To: Pinski, Andrew > Cc: Maxim Kuvyrkov ; Linaro Toolchain > ; Szabolcs Nagy ; > Ellcey, Steve > Subject: Re: ILP32 toolchain status update > > On 8 November 2017 at 16:56, Pinski, Andrew wrote: >> What env are you using? Are the glibc versions on the same between ILP32 >> and LP64? Because when that was true I did not have any issues with >> libthread_db. >> > > I didn't run gdb tests in ILP32 env, and I don't have such env. I got > gdb.sum from Steve on 18 Oct. You are on the cc as well. All my analysis is > based on that gdb.sum. > >> Anyways I did not see some of those failures listed below when using the >> correct setup. > > OK, can you send me a gdb.sum? > > -- > Yao Qi ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
