* GDBserver ports cleanup @ 2020-05-12 16:47 Simon Marchi 2020-05-12 20:26 ` Christian Biesinger 2020-05-13 18:36 ` Joseph Myers 0 siblings, 2 replies; 10+ messages in thread From: Simon Marchi @ 2020-05-12 16:47 UTC (permalink / raw) To: gdb-patches Hi, I would like to propose a cleanup in the stale / unused / outdated GDBserver ports (the same could be done with GDB, but I'm tackling GDBserver for now). It is a recurring theme that when doing changes in common functions, we need to change files that we can't build. We sometimes find blatant mistakes that wouldn't even compile in these files, which shows that nobody is building them. If nobody is using them, I'd like to remove them, as it takes up some precious developer time to consider them in our changes. It also confuses people as to why we keep code that doesn't build in our repo... Looking at the *-low.cc files, here are the platforms GDBserver supports today: - linux-aarch32 - linux-aarch64 - linux-arm - linux-bfin - linux-cris - linux-crisv32 - linux-ia64 - linux-m32r - linux-m68k - linux-mips - linux-nios2 - linux-ppc - linux-riscv - linux-s390 - linux-sh - linux-sparc - linux-tic6x - linux-tile - linux-x86 - linux-xtensa - lynx-i386 - lynx-ppc - nto-x86 - win32-arm - win32-i386 The ones I'm thinking should go for sure are lynx (LynxOS) and nto (Neutrino). As far as I know, it's not possible to build GDBserver for these without having access to non-publicly available toolchains/sysroots from the vendors, so it's not reasonable to expect the community to maintain it. And seeing that nobody made changes specific to these ports in many years, I conclude that nobody is really using that code. Of course, if somebody has access to them and would like to maintain them, I'm not against that. We could also do some cleanup in the linux ones, as there are likely a few architectures that could be considered obsolete. However, in the case of Linux, somebody motivated could always build a toolchain and sysroot themselves. For reference, here are the architectures not currently supported in the upstream Linux kernel: - bfin (removed in 4.16) - cris (and crisv32 I guess) (removed in 4.17) - m32r (removed in 4.16) - tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't seem to be development since ~2012) - tile (removed in 4.16) In my opinion, we should remove the corresponding GDBserver ports, unless somebody shows interest for them. For reference, Linux 4.16 has been released more than two years ago. About Windows support for ARM, I don't really know about it. I think that our port was targeting Windows CE [2], which can probably be considered obsolete. However, Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really know if the current GDBserver code would help for that or not. In doubt, I won't propose to remove it. Please let me know what you think. Also, does anybody know if you deprecation/removal process is written somewhere? I know we discussed it in the past, but I can't find it. Simon [1] http://www.linux-c6x.org/wiki/index.php/Releases [2] https://en.wikipedia.org/wiki/Windows_Embedded_Compact [3] https://docs.microsoft.com/en-us/windows/arm/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-12 16:47 GDBserver ports cleanup Simon Marchi @ 2020-05-12 20:26 ` Christian Biesinger 2020-05-13 12:01 ` Pedro Alves 2020-05-13 12:37 ` Luis Machado 2020-05-13 18:36 ` Joseph Myers 1 sibling, 2 replies; 10+ messages in thread From: Christian Biesinger @ 2020-05-12 20:26 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb-patches On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> wrote: > > Hi, > > I would like to propose a cleanup in the stale / unused / outdated GDBserver > ports (the same could be done with GDB, but I'm tackling GDBserver for now). > > It is a recurring theme that when doing changes in common functions, we need to > change files that we can't build. We sometimes find blatant mistakes that wouldn't > even compile in these files, which shows that nobody is building them. If nobody > is using them, I'd like to remove them, as it takes up some precious developer time > to consider them in our changes. It also confuses people as to why we keep code > that doesn't build in our repo... > > Looking at the *-low.cc files, here are the platforms GDBserver supports today: > > - linux-aarch32 > - linux-aarch64 > - linux-arm > - linux-bfin > - linux-cris > - linux-crisv32 > - linux-ia64 > - linux-m32r > - linux-m68k > - linux-mips > - linux-nios2 > - linux-ppc > - linux-riscv > - linux-s390 > - linux-sh > - linux-sparc > - linux-tic6x > - linux-tile > - linux-x86 > - linux-xtensa > - lynx-i386 > - lynx-ppc > - nto-x86 > - win32-arm > - win32-i386 > > The ones I'm thinking should go for sure are lynx (LynxOS) and nto (Neutrino). As > far as I know, it's not possible to build GDBserver for these without having access > to non-publicly available toolchains/sysroots from the vendors, so it's not > reasonable to expect the community to maintain it. And seeing that nobody made changes > specific to these ports in many years, I conclude that nobody is really using that code. > Of course, if somebody has access to them and would like to maintain them, I'm not against > that. > > We could also do some cleanup in the linux ones, as there are likely a few architectures > that could be considered obsolete. However, in the case of Linux, somebody motivated > could always build a toolchain and sysroot themselves. For reference, here are the > architectures not currently supported in the upstream Linux kernel: > > - bfin (removed in 4.16) > - cris (and crisv32 I guess) (removed in 4.17) > - m32r (removed in 4.16) > - tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't > seem to be development since ~2012) > - tile (removed in 4.16) > > In my opinion, we should remove the corresponding GDBserver ports, unless somebody shows > interest for them. For reference, Linux 4.16 has been released more than two years ago. > > About Windows support for ARM, I don't really know about it. I think that our port > was targeting Windows CE [2], which can probably be considered obsolete. However, > Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really > know if the current GDBserver code would help for that or not. In doubt, I won't propose > to remove it. If indeed the win32-arm support handles Windows 10, I think it would be good to keep it, but I am not sure it does -- win32-arm-low.cc does have these lines: /* Correct in either endianness. We do not support Thumb yet. */ static const unsigned long arm_wince_breakpoint = 0xe6000010; #define arm_wince_breakpoint_len 4 Note mention of WinCE. Also, I am not so familiar with Thumb but I believe that's widely used on ARM these days? So my vote would be to remove this for now and if someone wants to revive it there's the git history. Christian > > Please let me know what you think. > > Also, does anybody know if you deprecation/removal process is written somewhere? I know > we discussed it in the past, but I can't find it. > > Simon > > [1] http://www.linux-c6x.org/wiki/index.php/Releases > [2] https://en.wikipedia.org/wiki/Windows_Embedded_Compact > [3] https://docs.microsoft.com/en-us/windows/arm/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-12 20:26 ` Christian Biesinger @ 2020-05-13 12:01 ` Pedro Alves 2020-05-13 14:45 ` Simon Marchi 2020-05-13 12:37 ` Luis Machado 1 sibling, 1 reply; 10+ messages in thread From: Pedro Alves @ 2020-05-13 12:01 UTC (permalink / raw) To: Christian Biesinger, Simon Marchi; +Cc: gdb-patches On 5/12/20 9:26 PM, Christian Biesinger via Gdb-patches wrote: > On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches >> About Windows support for ARM, I don't really know about it. I think that our port >> was targeting Windows CE [2], which can probably be considered obsolete. However, >> Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really >> know if the current GDBserver code would help for that or not. In doubt, I won't propose >> to remove it. > > If indeed the win32-arm support handles Windows 10, I think it would > be good to keep it, but I am not sure it does -- win32-arm-low.cc does > have these lines: > /* Correct in either endianness. We do not support Thumb yet. */ > static const unsigned long arm_wince_breakpoint = 0xe6000010; > #define arm_wince_breakpoint_len 4 > > Note mention of WinCE. Also, I am not so familiar with Thumb but I > believe that's widely used on ARM these days? > > So my vote would be to remove this for now and if someone wants to > revive it there's the git history. win32-arm support in gdbserver is only for Windows CE. I was the one who wrote it, it was the reason I got into GDB hacking in the first place. :-) There was no Windows for ARM back then. I don't object removing it. I haven't built a compiler or gdbserver for WinCE in years, and I doubt anyone else has^W^W^W^W^W^W^W^W^W^W^W^W Wow, I just found out that someone forked my old cegcc project, and updated it based on a much more modern GCC: https://max.kellermann.name/projects/cegcc/ I had no idea. Look like he has some local GDB in his github, though dated from 2016/2018. If you do remove it, then you'll want to remove all the code guarded under _WIN32_WCE in win32-low.cc, and also wincecompat.c. There's also ARM WinCE support on the GDB side, in arm-wince-tdep.c. I'm not sure there's that much salvageable for an eventual Windows for ARM port. For example, Windows for ARM is strictly Thumb-2, while I don't recall ever considering Thumb-2 back then. WinCE was FPA, I believe, while Windows for ARM is VFP. The ABIs are just different, and WinCE is weird beyond belief. (no "errno", no concept for "current directory", etc.). Other than nostalgia for being what got me into GDB, I really won't miss it myself. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-13 12:01 ` Pedro Alves @ 2020-05-13 14:45 ` Simon Marchi 2020-05-13 15:01 ` Pedro Alves 0 siblings, 1 reply; 10+ messages in thread From: Simon Marchi @ 2020-05-13 14:45 UTC (permalink / raw) To: Pedro Alves, Christian Biesinger; +Cc: gdb-patches On 2020-05-13 8:01 a.m., Pedro Alves wrote: > On 5/12/20 9:26 PM, Christian Biesinger via Gdb-patches wrote: >> On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches > >>> About Windows support for ARM, I don't really know about it. I think that our port >>> was targeting Windows CE [2], which can probably be considered obsolete. However, >>> Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really >>> know if the current GDBserver code would help for that or not. In doubt, I won't propose >>> to remove it. >> >> If indeed the win32-arm support handles Windows 10, I think it would >> be good to keep it, but I am not sure it does -- win32-arm-low.cc does >> have these lines: >> /* Correct in either endianness. We do not support Thumb yet. */ >> static const unsigned long arm_wince_breakpoint = 0xe6000010; >> #define arm_wince_breakpoint_len 4 >> >> Note mention of WinCE. Also, I am not so familiar with Thumb but I >> believe that's widely used on ARM these days? >> >> So my vote would be to remove this for now and if someone wants to >> revive it there's the git history. > win32-arm support in gdbserver is only for Windows CE. I was the one > who wrote it, it was the reason I got into GDB hacking in the first > place. :-) There was no Windows for ARM back then. > > I don't object removing it. I haven't built a compiler or gdbserver > for WinCE in years, and I doubt anyone else has^W^W^W^W^W^W^W^W^W^W^W^W > Wow, I just found out that someone forked my old cegcc project, and > updated it based on a much more modern GCC: > https://max.kellermann.name/projects/cegcc/ > I had no idea. Look like he has some local GDB in his github, though > dated from 2016/2018. > > If you do remove it, then you'll want to remove all the code guarded under > _WIN32_WCE in win32-low.cc, and also wincecompat.c. There's also > ARM WinCE support on the GDB side, in arm-wince-tdep.c. > > I'm not sure there's that much salvageable for an eventual Windows for ARM > port. For example, Windows for ARM is strictly Thumb-2, while I don't recall > ever considering Thumb-2 back then. WinCE was FPA, I believe, while Windows > for ARM is VFP. The ABIs are just different, and WinCE is weird beyond belief. > (no "errno", no concept for "current directory", etc.). > > Other than nostalgia for being what got me into GDB, I really won't miss it > myself. Thanks for the storytelling, I enjoyed it :). If removing support for WinCE ends up simplifying win32-low.cc, it is a net gain, since that file is used today. Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-13 14:45 ` Simon Marchi @ 2020-05-13 15:01 ` Pedro Alves 0 siblings, 0 replies; 10+ messages in thread From: Pedro Alves @ 2020-05-13 15:01 UTC (permalink / raw) To: Simon Marchi, Christian Biesinger; +Cc: gdb-patches On 5/13/20 3:45 PM, Simon Marchi wrote: > Thanks for the storytelling, I enjoyed it :). > :-) > If removing support for WinCE ends up simplifying win32-low.cc, it is a net gain, > since that file is used today. Yes, and removing all that should make it easier to continue the effort to merging gdb's windows-nat.c and gdbserver's win32-low.cc. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-12 20:26 ` Christian Biesinger 2020-05-13 12:01 ` Pedro Alves @ 2020-05-13 12:37 ` Luis Machado 2020-05-13 13:11 ` Alan Hayward 1 sibling, 1 reply; 10+ messages in thread From: Luis Machado @ 2020-05-13 12:37 UTC (permalink / raw) To: Christian Biesinger, Simon Marchi; +Cc: gdb-patches, Alan Hayward On 5/12/20 5:26 PM, Christian Biesinger via Gdb-patches wrote: > On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches > <gdb-patches@sourceware.org> wrote: >> >> Hi, >> >> I would like to propose a cleanup in the stale / unused / outdated GDBserver >> ports (the same could be done with GDB, but I'm tackling GDBserver for now). >> >> It is a recurring theme that when doing changes in common functions, we need to >> change files that we can't build. We sometimes find blatant mistakes that wouldn't >> even compile in these files, which shows that nobody is building them. If nobody >> is using them, I'd like to remove them, as it takes up some precious developer time >> to consider them in our changes. It also confuses people as to why we keep code >> that doesn't build in our repo... >> >> Looking at the *-low.cc files, here are the platforms GDBserver supports today: >> >> - linux-aarch32 >> - linux-aarch64 >> - linux-arm >> - linux-bfin >> - linux-cris >> - linux-crisv32 >> - linux-ia64 >> - linux-m32r >> - linux-m68k >> - linux-mips >> - linux-nios2 >> - linux-ppc >> - linux-riscv >> - linux-s390 >> - linux-sh >> - linux-sparc >> - linux-tic6x >> - linux-tile >> - linux-x86 >> - linux-xtensa >> - lynx-i386 >> - lynx-ppc >> - nto-x86 >> - win32-arm >> - win32-i386 >> >> The ones I'm thinking should go for sure are lynx (LynxOS) and nto (Neutrino). As >> far as I know, it's not possible to build GDBserver for these without having access >> to non-publicly available toolchains/sysroots from the vendors, so it's not >> reasonable to expect the community to maintain it. And seeing that nobody made changes >> specific to these ports in many years, I conclude that nobody is really using that code. >> Of course, if somebody has access to them and would like to maintain them, I'm not against >> that. >> >> We could also do some cleanup in the linux ones, as there are likely a few architectures >> that could be considered obsolete. However, in the case of Linux, somebody motivated >> could always build a toolchain and sysroot themselves. For reference, here are the >> architectures not currently supported in the upstream Linux kernel: >> >> - bfin (removed in 4.16) >> - cris (and crisv32 I guess) (removed in 4.17) >> - m32r (removed in 4.16) >> - tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't >> seem to be development since ~2012) >> - tile (removed in 4.16) >> >> In my opinion, we should remove the corresponding GDBserver ports, unless somebody shows >> interest for them. For reference, Linux 4.16 has been released more than two years ago. >> >> About Windows support for ARM, I don't really know about it. I think that our port >> was targeting Windows CE [2], which can probably be considered obsolete. However, >> Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really >> know if the current GDBserver code would help for that or not. In doubt, I won't propose >> to remove it. > > If indeed the win32-arm support handles Windows 10, I think it would > be good to keep it, but I am not sure it does -- win32-arm-low.cc does > have these lines: > /* Correct in either endianness. We do not support Thumb yet. */ > static const unsigned long arm_wince_breakpoint = 0xe6000010; > #define arm_wince_breakpoint_len 4 > > Note mention of WinCE. Also, I am not so familiar with Thumb but I > believe that's widely used on ARM these days? > > So my vote would be to remove this for now and if someone wants to > revive it there's the git history. Agreed. I think we should remove it. If we need a port of gdbserver for Windows on ARM in the future, we'd benefit from coming up with fresh code to reflect the current state of the architecture. I'm cc-ing Alan, in case he has any feedback. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-13 12:37 ` Luis Machado @ 2020-05-13 13:11 ` Alan Hayward 2020-05-13 14:47 ` Simon Marchi 0 siblings, 1 reply; 10+ messages in thread From: Alan Hayward @ 2020-05-13 13:11 UTC (permalink / raw) To: Luis Machado; +Cc: Christian Biesinger, Simon Marchi, gdb-patches, nd > On 13 May 2020, at 13:37, Luis Machado <luis.machado@linaro.org> wrote: > > On 5/12/20 5:26 PM, Christian Biesinger via Gdb-patches wrote: >> On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches >> <gdb-patches@sourceware.org> wrote: >>> >>> Hi, >>> >>> I would like to propose a cleanup in the stale / unused / outdated GDBserver >>> ports (the same could be done with GDB, but I'm tackling GDBserver for now). >>> >>> It is a recurring theme that when doing changes in common functions, we need to >>> change files that we can't build. We sometimes find blatant mistakes that wouldn't >>> even compile in these files, which shows that nobody is building them. If nobody >>> is using them, I'd like to remove them, as it takes up some precious developer time >>> to consider them in our changes. It also confuses people as to why we keep code >>> that doesn't build in our repo... >>> >>> Looking at the *-low.cc files, here are the platforms GDBserver supports today: >>> >>> - linux-aarch32 >>> - linux-aarch64 >>> - linux-arm >>> - linux-bfin >>> - linux-cris >>> - linux-crisv32 >>> - linux-ia64 >>> - linux-m32r >>> - linux-m68k >>> - linux-mips >>> - linux-nios2 >>> - linux-ppc >>> - linux-riscv >>> - linux-s390 >>> - linux-sh >>> - linux-sparc >>> - linux-tic6x >>> - linux-tile >>> - linux-x86 >>> - linux-xtensa >>> - lynx-i386 >>> - lynx-ppc >>> - nto-x86 >>> - win32-arm >>> - win32-i386 >>> >>> The ones I'm thinking should go for sure are lynx (LynxOS) and nto (Neutrino). As >>> far as I know, it's not possible to build GDBserver for these without having access >>> to non-publicly available toolchains/sysroots from the vendors, so it's not >>> reasonable to expect the community to maintain it. And seeing that nobody made changes >>> specific to these ports in many years, I conclude that nobody is really using that code. >>> Of course, if somebody has access to them and would like to maintain them, I'm not against >>> that. >>> >>> We could also do some cleanup in the linux ones, as there are likely a few architectures >>> that could be considered obsolete. However, in the case of Linux, somebody motivated >>> could always build a toolchain and sysroot themselves. For reference, here are the >>> architectures not currently supported in the upstream Linux kernel: >>> >>> - bfin (removed in 4.16) >>> - cris (and crisv32 I guess) (removed in 4.17) >>> - m32r (removed in 4.16) >>> - tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't >>> seem to be development since ~2012) >>> - tile (removed in 4.16) >>> >>> In my opinion, we should remove the corresponding GDBserver ports, unless somebody shows >>> interest for them. For reference, Linux 4.16 has been released more than two years ago. >>> >>> About Windows support for ARM, I don't really know about it. I think that our port >>> was targeting Windows CE [2], which can probably be considered obsolete. However, >>> Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really >>> know if the current GDBserver code would help for that or not. In doubt, I won't propose >>> to remove it. >> If indeed the win32-arm support handles Windows 10, I think it would >> be good to keep it, but I am not sure it does -- win32-arm-low.cc does >> have these lines: >> /* Correct in either endianness. We do not support Thumb yet. */ >> static const unsigned long arm_wince_breakpoint = 0xe6000010; >> #define arm_wince_breakpoint_len 4 >> Note mention of WinCE. Also, I am not so familiar with Thumb but I >> believe that's widely used on ARM these days? >> So my vote would be to remove this for now and if someone wants to >> revive it there's the git history. > > Agreed. I think we should remove it. > > If we need a port of gdbserver for Windows on ARM in the future, we'd benefit from coming up with fresh code to reflect the current state of the architecture. > > I'm cc-ing Alan, in case he has any feedback. The recent Windows on Arm is AArch64, so I suspect it’d need a win64-aarch64-low.cc. Agreed that we don’t care about the old windows CE stuff. And given that win32-arm-low.cc is only 160 lines, I don’t think we’re missing much by getting rid of it. I think tic6x was done by Yao Qi. Alan. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-13 13:11 ` Alan Hayward @ 2020-05-13 14:47 ` Simon Marchi 0 siblings, 0 replies; 10+ messages in thread From: Simon Marchi @ 2020-05-13 14:47 UTC (permalink / raw) To: Alan Hayward, Luis Machado; +Cc: Christian Biesinger, gdb-patches, nd On 2020-05-13 9:11 a.m., Alan Hayward wrote: > The recent Windows on Arm is AArch64, so I suspect it’d need a win64-aarch64-low.cc. > > Agreed that we don’t care about the old windows CE stuff. And given that win32-arm-low.cc is only 160 lines, I don’t think we’re missing much by getting rid of it. > > I think tic6x was done by Yao Qi. > > Alan. Thanks both for your input. Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-12 16:47 GDBserver ports cleanup Simon Marchi 2020-05-12 20:26 ` Christian Biesinger @ 2020-05-13 18:36 ` Joseph Myers 2020-05-13 18:40 ` Simon Marchi 1 sibling, 1 reply; 10+ messages in thread From: Joseph Myers @ 2020-05-13 18:36 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb-patches On Tue, 12 May 2020, Simon Marchi via Gdb-patches wrote: > - tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't > seem to be development since ~2012) I've no idea whether Linux on C6x is actively maintained, but the port is there in arch/c6x/. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDBserver ports cleanup 2020-05-13 18:36 ` Joseph Myers @ 2020-05-13 18:40 ` Simon Marchi 0 siblings, 0 replies; 10+ messages in thread From: Simon Marchi @ 2020-05-13 18:40 UTC (permalink / raw) To: Joseph Myers; +Cc: gdb-patches On 2020-05-13 2:36 p.m., Joseph Myers wrote: > On Tue, 12 May 2020, Simon Marchi via Gdb-patches wrote: > >> - tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't >> seem to be development since ~2012) > > I've no idea whether Linux on C6x is actively maintained, but the port is > there in arch/c6x/. Oh, my bad, I missed it. I don't propose to remove this one then. Simon ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-05-13 18:40 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-12 16:47 GDBserver ports cleanup Simon Marchi 2020-05-12 20:26 ` Christian Biesinger 2020-05-13 12:01 ` Pedro Alves 2020-05-13 14:45 ` Simon Marchi 2020-05-13 15:01 ` Pedro Alves 2020-05-13 12:37 ` Luis Machado 2020-05-13 13:11 ` Alan Hayward 2020-05-13 14:47 ` Simon Marchi 2020-05-13 18:36 ` Joseph Myers 2020-05-13 18:40 ` Simon Marchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).