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
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
- [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.
- [GDB] Handle ILP32 siginfo layout
The change to aarch64_linux_siginfo_fixup fixes that.
- [GDB] Inferior call passing pointer argument.
The change to aarch64_gdbarch_init fixes that.
- Handle shared libraries
The change to aarch64_linux_init_abi fixes that.
- [GDB] GDB resolves ifunc functions,
The change to aarch64_gdbarch_init fixes that IIRC.
- [GDB] Gdbserver support for ILP32.
The change to aarch64_linux_read_description fixes that.
Thanks, Andrew
-----Original Message----- From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Maxim Kuvyrkov Sent: Tuesday, November 7, 2017 4:40 AM To: Linaro Toolchain linaro-toolchain@lists.linaro.org Cc: Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com 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
On 7 November 2017 at 13:35, Pinski, Andrew Andrew.Pinski@cavium.com 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.
- [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)
- [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
- [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})
- 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-display.exp: IN: after rerun (2) FAIL: gdb.base/solib-display.exp: IN: display main_global FAIL: gdb.base/solib-display.exp: IN: display a_local FAIL: gdb.base/solib-display.exp: IN: display a_static FAIL: gdb.base/solib-display.exp: IN: continue FAIL: gdb.base/solib-display.exp: SEP: display (int) a_global FAIL: gdb.base/solib-display.exp: SEP: display (int) b_global FAIL: gdb.base/solib-display.exp: SEP: display (int) c_global FAIL: gdb.base/solib-display.exp: SEP: after rerun FAIL: gdb.base/solib-display.exp: SEP: after rerun (2) FAIL: gdb.base/solib-display.exp: SEP: display main_global FAIL: gdb.base/solib-display.exp: SEP: display a_local FAIL: gdb.base/solib-display.exp: SEP: display a_static FAIL: gdb.base/solib-display.exp: SEP: continue FAIL: gdb.base/solib-symbol.exp: foo in libmd FAIL: gdb.base/solib-symbol.exp: foo2 in mdlib FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 nodebug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 nodebug, lib2 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 debug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 debug, lib2 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 nodebug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 nodebug, lib2 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 debug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 debug, lib2 first (the program exited)
- [GDB] GDB resolves ifunc functions,
The change to aarch64_gdbarch_init fixes that IIRC.
FAIL: gdb.base/gnu-ifunc.exp: p gnu_ifunc (3) FAIL: gdb.base/gnu-ifunc.exp: resolver received HWCAP FAIL: gdb.base/gnu-ifunc.exp: continue to break-at-nextcall FAIL: gdb.base/gnu-ifunc.exp: nextcall gnu_ifunc skipped FAIL: gdb.base/gnu-ifunc.exp: p gnu_ifunc executing FAIL: gdb.base/gnu-ifunc.exp: info sym gnu_ifunc executing FAIL: gdb.base/gnu-ifunc.exp: info sym <gnu_ifunc-address>
- [GDB] Gdbserver support for ILP32.
The change to aarch64_linux_read_description fixes that.
That is not enough, GDBserver (LP64) needs to fix up siginfo for ILP32 program, like what GDB does. GDBserver uses libthread_db too. There is also tracepoint and fast tracepoint support in GDBserver. I don't expect them supported in ILP32.
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.
Anyways I did not see some of those failures listed below when using the correct setup.
-----Original Message----- From: Yao Qi [mailto:yao.qi@linaro.org] Sent: Wednesday, November 8, 2017 1:16 AM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Maxim Kuvyrkov maxim.kuvyrkov@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On 7 November 2017 at 13:35, Pinski, Andrew Andrew.Pinski@cavium.com 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.
- [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)
- [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
- [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})
- 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-display.exp: IN: after rerun (2) FAIL: gdb.base/solib-display.exp: IN: display main_global FAIL: gdb.base/solib-display.exp: IN: display a_local FAIL: gdb.base/solib-display.exp: IN: display a_static FAIL: gdb.base/solib-display.exp: IN: continue FAIL: gdb.base/solib-display.exp: SEP: display (int) a_global FAIL: gdb.base/solib-display.exp: SEP: display (int) b_global FAIL: gdb.base/solib-display.exp: SEP: display (int) c_global FAIL: gdb.base/solib-display.exp: SEP: after rerun FAIL: gdb.base/solib-display.exp: SEP: after rerun (2) FAIL: gdb.base/solib-display.exp: SEP: display main_global FAIL: gdb.base/solib-display.exp: SEP: display a_local FAIL: gdb.base/solib-display.exp: SEP: display a_static FAIL: gdb.base/solib-display.exp: SEP: continue FAIL: gdb.base/solib-symbol.exp: foo in libmd FAIL: gdb.base/solib-symbol.exp: foo2 in mdlib FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 nodebug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 nodebug, lib2 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 debug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 nodebug, lib2 debug, lib2 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 nodebug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 nodebug, lib2 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 debug, lib1 first (the program exited) FAIL: gdb.base/solib-weak.exp: setting breakpoint at bar FAIL: gdb.base/solib-weak.exp: run to breakpoint - lib1 debug, lib2 debug, lib2 first (the program exited)
- [GDB] GDB resolves ifunc functions,
The change to aarch64_gdbarch_init fixes that IIRC.
FAIL: gdb.base/gnu-ifunc.exp: p gnu_ifunc (3) FAIL: gdb.base/gnu-ifunc.exp: resolver received HWCAP FAIL: gdb.base/gnu-ifunc.exp: continue to break-at-nextcall FAIL: gdb.base/gnu-ifunc.exp: nextcall gnu_ifunc skipped FAIL: gdb.base/gnu-ifunc.exp: p gnu_ifunc executing FAIL: gdb.base/gnu-ifunc.exp: info sym gnu_ifunc executing FAIL: gdb.base/gnu-ifunc.exp: info sym <gnu_ifunc-address>
- [GDB] Gdbserver support for ILP32.
The change to aarch64_linux_read_description fixes that.
That is not enough, GDBserver (LP64) needs to fix up siginfo for ILP32 program, like what GDB does. GDBserver uses libthread_db too. There is also tracepoint and fast tracepoint support in GDBserver. I don't expect them supported in ILP32.
-- Yao Qi
On 8 November 2017 at 16:56, Pinski, Andrew Andrew.Pinski@cavium.com 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?
I thought the decision Linaro/Arm was going to take over the development of the ILP32? What happened to that decision?
Thanks, Andrew
-----Original Message----- From: Yao Qi [mailto:yao.qi@linaro.org] Sent: Wednesday, November 8, 2017 9:50 AM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Maxim Kuvyrkov maxim.kuvyrkov@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On 8 November 2017 at 16:56, Pinski, Andrew Andrew.Pinski@cavium.com 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
On Nov 8, 2017, at 9:03 PM, Pinski, Andrew Andrew.Pinski@cavium.com 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.qi@linaro.org] Sent: Wednesday, November 8, 2017 9:50 AM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Maxim Kuvyrkov maxim.kuvyrkov@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On 8 November 2017 at 16:56, Pinski, Andrew Andrew.Pinski@cavium.com 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
Where such a decision was discussed?
This was discussed back in the end of June. Mark Hambleton of ARM sent a response to Cavium to that effect.
-----Original Message----- From: Maxim Kuvyrkov [mailto:maxim.kuvyrkov@linaro.org] Sent: Wednesday, November 8, 2017 10:32 PM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Yao Qi yao.qi@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On Nov 8, 2017, at 9:03 PM, Pinski, Andrew Andrew.Pinski@cavium.com 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.qi@linaro.org] Sent: Wednesday, November 8, 2017 9:50 AM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Maxim Kuvyrkov maxim.kuvyrkov@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On 8 November 2017 at 16:56, Pinski, Andrew Andrew.Pinski@cavium.com 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
On Nov 9, 2017, at 9:44 AM, Pinski, Andrew Andrew.Pinski@cavium.com wrote:
Where such a decision was discussed?
This was discussed back in the end of June. Mark Hambleton of ARM sent a response to Cavium to that effect.
Hi Andrew,
There must have been a miscommunication then. ARM did not ask Linaro to take over development of ILP32. ARM has asked Linaro to produce a binary cross-toolchain from components published on upstream ILP32 branches.
Linaro has no current plans to work on ILP32 support in binutils/gdb/glibc. We do plan to finish ILP32 sanitizer support in GCC -- because Adhemerval has the most experience with AArch64/AArch32 sanitizers in ARM ecosystem.
Returning to GDB failures, it seems that patches you referenced (posted in March 2017) do not address the debugger deficiencies listed in at the start of this thread. Yao will follow up on that.
-- Maxim Kuvyrkov www.linaro.org
-----Original Message----- From: Maxim Kuvyrkov [mailto:maxim.kuvyrkov@linaro.org] Sent: Wednesday, November 8, 2017 10:32 PM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Yao Qi yao.qi@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On Nov 8, 2017, at 9:03 PM, Pinski, Andrew Andrew.Pinski@cavium.com 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.qi@linaro.org] Sent: Wednesday, November 8, 2017 9:50 AM To: Pinski, Andrew Andrew.Pinski@cavium.com Cc: Maxim Kuvyrkov maxim.kuvyrkov@linaro.org; Linaro Toolchain linaro-toolchain@lists.linaro.org; Szabolcs Nagy szabolcs.nagy@arm.com; Ellcey, Steve Steve.Ellcey@cavium.com Subject: Re: ILP32 toolchain status update
On 8 November 2017 at 16:56, Pinski, Andrew Andrew.Pinski@cavium.com 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
On 08/11/2017 15:49, Yao Qi wrote:
On 8 November 2017 at 16:56, Pinski, Andrew Andrew.Pinski@cavium.com 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).
On 7 November 2017 at 13:35, Pinski, Andrew Andrew.Pinski@cavium.com 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
Hi Andrew, These two patches are the patches Steve sent to us some days ago, and we've already created a branch carrying these two patches. According to the test results sent from Steve, the patches don't reach the bar to merge them, so some one still has to improve them, and get them merged.
It is a separate discussion about who will do the work.
linaro-toolchain@lists.linaro.org
-
Adhemerval Zanella -
Maxim Kuvyrkov -
Pinski, Andrew -
Yao Qi