ILP32 toolchain status update

[Maxim Kuvyrkov]

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

[Pinski, Andrew]

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

Post by Maxim Kuvyrkov
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.

Post by Maxim Kuvyrkov
3. [GDB] Handle ILP32 siginfo layout

The change to aarch64_linux_siginfo_fixup fixes that.

Post by Maxim Kuvyrkov
4. [GDB] Inferior call passing pointer argument.

The change to aarch64_gdbarch_init fixes that.

Post by Maxim Kuvyrkov
5. Handle shared libraries

The change to aarch64_linux_init_abi fixes that.

Post by Maxim Kuvyrkov
6. [GDB] GDB resolves ifunc functions,

The change to aarch64_gdbarch_init fixes that IIRC.

Post by Maxim Kuvyrkov
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-***@lists.linaro.org] On Behalf Of Maxim Kuvyrkov
Sent: Tuesday, November 7, 2017 4:40 AM
To: Linaro Toolchain <linaro-***@lists.linaro.org>
Cc: Szabolcs Nagy <***@arm.com>; Ellcey, Steve <***@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-***@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Yao Qi]

Post by Pinski, Andrew
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.

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
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)

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
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

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
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})

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
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)

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
6. [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>

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
7. [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]

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?

[Adhemerval Zanella]

Post by Yao Qi

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

[Maxim Kuvyrkov]

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-----
Sent: Wednesday, November 8, 2017 9:50 AM
Subject: Re: ILP32 toolchain status update

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

[Pinski, Andrew]

Post by Maxim Kuvyrkov
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:***@linaro.org]
Sent: Wednesday, November 8, 2017 10:32 PM
To: Pinski, Andrew <***@cavium.com>
Cc: Yao Qi <***@linaro.org>; Linaro Toolchain <linaro-***@lists.linaro.org>; Szabolcs Nagy <***@arm.com>; Ellcey, Steve <***@cavium.com>
Subject: Re: ILP32 toolchain status update

Post by Maxim Kuvyrkov
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

Post by Maxim Kuvyrkov
Thanks,
Andrew
-----Original Message-----
Sent: Wednesday, November 8, 2017 9:50 AM
Subject: Re: ILP32 toolchain status update

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

[Maxim Kuvyrkov]

Post by Pinski, Andrew

Post by Maxim Kuvyrkov
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

Post by Pinski, Andrew
-----Original Message-----
Sent: Wednesday, November 8, 2017 10:32 PM
Subject: Re: ILP32 toolchain status update

Post by Maxim Kuvyrkov
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

Post by Maxim Kuvyrkov
Thanks,
Andrew
-----Original Message-----
Sent: Wednesday, November 8, 2017 9:50 AM
Subject: Re: ILP32 toolchain status update

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

[Yao Qi]

Post by Pinski, Andrew
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.