All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] libsanitizer: Enable GCC sanitizers
@ 2014-09-15  4:00 Dan McGregor
  2014-09-15 15:00 ` Burton, Ross
  0 siblings, 1 reply; 9+ messages in thread
From: Dan McGregor @ 2014-09-15  4:00 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

From: Dan McGregor <dan.mcgregor@usask.ca>

AddressSanitizer is a fast memory error detector.
ThreadSanitizer detects data races.
UBSanitizer detectes undefined behaviour.

All consist of compiler instrumentation and a run-time library.
The compiler instrumentation was already enabled, this builds
the run-time library component.

Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
---
 meta/conf/distro/include/tcmode-default.inc   |  1 +
 meta/recipes-devtools/gcc/libsanitizer.inc    | 49 +++++++++++++++++++++++++++
 meta/recipes-devtools/gcc/libsanitizer_4.8.bb |  3 ++
 meta/recipes-devtools/gcc/libsanitizer_4.9.bb |  3 ++
 4 files changed, 56 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/libsanitizer.inc
 create mode 100644 meta/recipes-devtools/gcc/libsanitizer_4.8.bb
 create mode 100644 meta/recipes-devtools/gcc/libsanitizer_4.9.bb

diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 6c0f102..3eed903 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -35,6 +35,7 @@ PREFERRED_VERSION_gcc-cross-initial-${TARGET_ARCH}
?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-crosssdk-${SDK_ARCH} ?= "${SDKGCCVERSION}"
 PREFERRED_VERSION_gcc-crosssdk-initial-${SDK_ARCH} ?= "${SDKGCCVERSION}"
 PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} ?=
"${GCCVERSION}"
+PREFERRED_VERSION_libsanitizer ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-runtime ?= "${GCCVERSION}"
 PREFERRED_VERSION_nativesdk-gcc-runtime ?= "${SDKGCCVERSION}"
 PREFERRED_VERSION_libgcc ?= "${GCCVERSION}"
diff --git a/meta/recipes-devtools/gcc/libsanitizer.inc
b/meta/recipes-devtools/gcc/libsanitizer.inc
new file mode 100644
index 0000000..6d5f53e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/libsanitizer.inc
@@ -0,0 +1,49 @@
+require gcc-configure-common.inc
+
+EXTRA_OECONF_PATHS = "\
+    --with-sysroot=${STAGING_DIR_TARGET} \
+    --with-build-sysroot=${STAGING_DIR_TARGET} \
+"
+
+do_configure () {
+    mtarget=`echo ${TARGET_SYS} | sed -e s#-${SDKPKGSUFFIX}##`
+    target=`echo ${TARGET_SYS} | sed -e s#-${SDKPKGSUFFIX}##`
+    hardlinkdir ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$mtarget ${B}
+
+    echo "Configuring libsanitizer"
+    rm -rf ${B}/$target/libsanitizer/
+    mkdir -p ${B}/$target/libsanitizer/
+    # This is kind of gross, but it's an easy way to make configure happy
+    # without hacking it up to use the system stdc++ instead of the one it
+    # expects to be newly built.
+    rm -rf ${B}/$target/libstdc++-v3/
+    mkdir -p ${B}/$target/libstdc++-v3/src/
+    ln -s ${STAGING_LIBDIR}/libstdc++.la ${B}/$target/libstdc++-v3/src/
+    ln -s ${STAGING_LIBDIR}/libstdc++.so ${B}/$target/libstdc++-v3/src/
+    cd ${B}/$target/libsanitizer/
+    chmod a+x ${S}/libsanitizer/configure
+    ${S}/libsanitizer/configure ${CONFIGUREOPTS} ${EXTRA_OECONF}
+}
+
+do_compile () {
+    target=`echo ${TARGET_SYS} | sed -e s#-${SDKPKGSUFFIX}##`
+    cd ${B}/$target/libsanitizer/
+    oe_runmake MULTIBUILDTOP=${B}/$target/libsanitizer/
+}
+
+do_install () {
+    target=`echo ${TARGET_SYS} | sed -e s#-${SDKPKGSUFFIX}##`
+    cd ${B}/$target/libsanitizer/
+    oe_runmake 'DESTDIR=${D}' MULTIBUILDTOP=${B}/$target/libsanitizer/ install
+    if [ -d ${D}${infodir} ]; then
+        rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
+    fi
+    chown -R root:root ${D}
+}
+
+DEPENDS = "gcc-runtime"
+
+FILES_${PN}-dev += "\
+    ${libdir}/*preinit.o \
+    ${libdir}/*.spec \
+"
diff --git a/meta/recipes-devtools/gcc/libsanitizer_4.8.bb
b/meta/recipes-devtools/gcc/libsanitizer_4.8.bb
new file mode 100644
index 0000000..f3ced76
--- /dev/null
+++ b/meta/recipes-devtools/gcc/libsanitizer_4.8.bb
@@ -0,0 +1,3 @@
+require recipes-devtools/gcc/gcc-${PV}.inc
+require libsanitizer.inc
+
diff --git a/meta/recipes-devtools/gcc/libsanitizer_4.9.bb
b/meta/recipes-devtools/gcc/libsanitizer_4.9.bb
new file mode 100644
index 0000000..f3ced76
--- /dev/null
+++ b/meta/recipes-devtools/gcc/libsanitizer_4.9.bb
@@ -0,0 +1,3 @@
+require recipes-devtools/gcc/gcc-${PV}.inc
+require libsanitizer.inc
+
-- 
2.1.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-09-15  4:00 [PATCH v3] libsanitizer: Enable GCC sanitizers Dan McGregor
@ 2014-09-15 15:00 ` Burton, Ross
  2014-09-15 20:20   ` Dan McGregor
  0 siblings, 1 reply; 9+ messages in thread
From: Burton, Ross @ 2014-09-15 15:00 UTC (permalink / raw)
  To: Dan McGregor; +Cc: Patches and discussions about the oe-core layer

On 15 September 2014 05:00, Dan McGregor <danismostlikely@gmail.com> wrote:
> From: Dan McGregor <dan.mcgregor@usask.ca>
>
> AddressSanitizer is a fast memory error detector.
> ThreadSanitizer detects data races.
> UBSanitizer detectes undefined behaviour.
>
> All consist of compiler instrumentation and a run-time library.
> The compiler instrumentation was already enabled, this builds
> the run-time library component.
>
> Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>

git-am is not happy with this patch, claiming that it's malformed.
Can you try re-sending or pushing to a branch somewhere?

Ross


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-09-15 15:00 ` Burton, Ross
@ 2014-09-15 20:20   ` Dan McGregor
  2014-09-15 20:28     ` Burton, Ross
  0 siblings, 1 reply; 9+ messages in thread
From: Dan McGregor @ 2014-09-15 20:20 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Patches and discussions about the oe-core layer

On 15 September 2014 09:00, Burton, Ross <ross.burton@intel.com> wrote:
> On 15 September 2014 05:00, Dan McGregor <danismostlikely@gmail.com> wrote:
>> From: Dan McGregor <dan.mcgregor@usask.ca>
>>
>> AddressSanitizer is a fast memory error detector.
>> ThreadSanitizer detects data races.
>> UBSanitizer detectes undefined behaviour.
>>
>> All consist of compiler instrumentation and a run-time library.
>> The compiler instrumentation was already enabled, this builds
>> the run-time library component.
>>
>> Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
>
> git-am is not happy with this patch, claiming that it's malformed.
> Can you try re-sending or pushing to a branch somewhere?

Sure: http://bitbucket.org/dankm/openembedded-core.git, branch "sanitizers".

It has unrelated changes in it, but this one should be cherry-pickable.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-09-15 20:20   ` Dan McGregor
@ 2014-09-15 20:28     ` Burton, Ross
  2014-09-16 18:45       ` Dan McGregor
  0 siblings, 1 reply; 9+ messages in thread
From: Burton, Ross @ 2014-09-15 20:28 UTC (permalink / raw)
  To: Dan McGregor; +Cc: Patches and discussions about the oe-core layer

On 15 September 2014 21:20, Dan McGregor <danismostlikely@gmail.com> wrote:
>> git-am is not happy with this patch, claiming that it's malformed.
>> Can you try re-sending or pushing to a branch somewhere?
>
> Sure: http://bitbucket.org/dankm/openembedded-core.git, branch "sanitizers".
>
> It has unrelated changes in it, but this one should be cherry-pickable.

Thanks, I've pulled this into my unfreeze branch for when the 1.8 is
open.  Post updates if there are new patches and I'll rebase.

Ross


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-09-15 20:28     ` Burton, Ross
@ 2014-09-16 18:45       ` Dan McGregor
  2014-11-04 13:45         ` Burton, Ross
  0 siblings, 1 reply; 9+ messages in thread
From: Dan McGregor @ 2014-09-16 18:45 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Patches and discussions about the oe-core layer

On 15 September 2014 14:28, Burton, Ross <ross.burton@intel.com> wrote:
> On 15 September 2014 21:20, Dan McGregor <danismostlikely@gmail.com> wrote:
>>> git-am is not happy with this patch, claiming that it's malformed.
>>> Can you try re-sending or pushing to a branch somewhere?
>>
>> Sure: http://bitbucket.org/dankm/openembedded-core.git, branch "sanitizers".
>>
>> It has unrelated changes in it, but this one should be cherry-pickable.
>
> Thanks, I've pulled this into my unfreeze branch for when the 1.8 is
> open.  Post updates if there are new patches and I'll rebase.

No worries. There's a new version up now. I did some experiments with
other machines. Turns out it doesn't
work on aarch64.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-09-16 18:45       ` Dan McGregor
@ 2014-11-04 13:45         ` Burton, Ross
  2014-11-13 23:35           ` Dan McGregor
  0 siblings, 1 reply; 9+ messages in thread
From: Burton, Ross @ 2014-11-04 13:45 UTC (permalink / raw)
  To: Dan McGregor; +Cc: Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]

Hi Dan,

On 16 September 2014 19:45, Dan McGregor <danismostlikely@gmail.com> wrote:

> No worries. There's a new version up now. I did some experiments with
> other machines. Turns out it doesn't
> work on aarch64.
>

Said I'd merge these once 1.7 out and sadly there's some bad news:

|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/qemux86/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/work/i586-poky-linux/glibc/2.20-r0/git/csu/elf-init.c:86:
undefined reference to `__init_array_start'
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.9.1/ld:
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/qemux86/usr/lib/libc_nonshared.a(elf-init.oS):
relocation R_386_GOTOFF against undefined hidden symbol
`__init_array_start' can not be used when making a shared object
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.9.1/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:407: recipe for target 'libasan.la' failed

(
https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/87/steps/BuildImages/logs/stdio
)

|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/sysroots/imx53qsb/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/glibc/2.20-r0/git/csu/elf-init.c:87:
undefined reference to `__init_array_end'
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/glibc/2.20-r0/git/csu/elf-init.c:87:
undefined reference to `__init_array_start'
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
.libs/libasan.so.1.0.0: hidden symbol `__init_array_end' isn't defined
|
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit status
| make[2]: *** [libasan.la] Error 1

(
https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/85/steps/BuildImages/logs/stdio
)

ERROR: Nothing RPROVIDES 'libsanitizer' (but
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips/build/meta/recipes-core/packagegroups/
packagegroup-core-sdk.bb RDEPENDS on or otherwise requires it)
ERROR: libsanitizer was skipped: incompatible with host mips-poky-linux
(not in COMPATIBLE_HOST)

(
https://autobuilder.yoctoproject.org/main/builders/nightly-mips/builds/89/steps/BuildImages/logs/stdio
)

Will you be able to work on these?

Ross

[-- Attachment #2: Type: text/html, Size: 4939 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-11-04 13:45         ` Burton, Ross
@ 2014-11-13 23:35           ` Dan McGregor
  2014-12-10 11:58             ` Burton, Ross
  0 siblings, 1 reply; 9+ messages in thread
From: Dan McGregor @ 2014-11-13 23:35 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Patches and discussions about the oe-core layer

On 4 November 2014 07:45, Burton, Ross <ross.burton@intel.com> wrote:
> Hi Dan,
>
> On 16 September 2014 19:45, Dan McGregor <danismostlikely@gmail.com> wrote:
>>
>> No worries. There's a new version up now. I did some experiments with
>> other machines. Turns out it doesn't
>> work on aarch64.
>
>
> Said I'd merge these once 1.7 out and sadly there's some bad news:
>
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/qemux86/usr/lib/libc_nonshared.a(elf-init.oS):
> In function `__libc_csu_init':
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/work/i586-poky-linux/glibc/2.20-r0/git/csu/elf-init.c:86:
> undefined reference to `__init_array_start'
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.9.1/ld:
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/qemux86/usr/lib/libc_nonshared.a(elf-init.oS):
> relocation R_386_GOTOFF against undefined hidden symbol `__init_array_start'
> can not be used when making a shared object
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.9.1/ld:
> final link failed: Bad value
> | collect2: error: ld returned 1 exit status
> | Makefile:407: recipe for target 'libasan.la' failed
>
> (https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/87/steps/BuildImages/logs/stdio)
>
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/sysroots/imx53qsb/usr/lib/libc_nonshared.a(elf-init.oS):
> In function `__libc_csu_init':
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/glibc/2.20-r0/git/csu/elf-init.c:87:
> undefined reference to `__init_array_end'
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/glibc/2.20-r0/git/csu/elf-init.c:87:
> undefined reference to `__init_array_start'
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
> .libs/libasan.so.1.0.0: hidden symbol `__init_array_end' isn't defined
> |
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm-lsb/build/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
> final link failed: Bad value
> | collect2: error: ld returned 1 exit status
> | make[2]: *** [libasan.la] Error 1
>
> (https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/85/steps/BuildImages/logs/stdio)
>
> ERROR: Nothing RPROVIDES 'libsanitizer' (but
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips/build/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
> RDEPENDS on or otherwise requires it)
> ERROR: libsanitizer was skipped: incompatible with host mips-poky-linux (not
> in COMPATIBLE_HOST)
>
> (https://autobuilder.yoctoproject.org/main/builders/nightly-mips/builds/89/steps/BuildImages/logs/stdio)
>
> Will you be able to work on these?
>
> Ross

Looks like I needed to use the same security CFLAGS as gcc-runtime and
libgcc. There's a new version up on my bitbucket page.

I still haven't found an elegant solution to the package group issue
on MIPS/SPARC though.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-11-13 23:35           ` Dan McGregor
@ 2014-12-10 11:58             ` Burton, Ross
  2014-12-12  3:15               ` Dan McGregor
  0 siblings, 1 reply; 9+ messages in thread
From: Burton, Ross @ 2014-12-10 11:58 UTC (permalink / raw)
  To: Dan McGregor; +Cc: Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

Hi Dan,

On 13 November 2014 at 23:35, Dan McGregor <danismostlikely@gmail.com>
wrote:

> Looks like I needed to use the same security CFLAGS as gcc-runtime and
> libgcc. There's a new version up on my bitbucket page.
>

I see you're still using anonymous python instead of COMPATIBLE_HOST to
mark what architectures the sanitizers work on, can you change that?

For packagegroups, if my recollection is correct and the problem is that a
packagegroup wants to depend on packages which are architecture-specific, a
common trick is to do something like this:

SANITIZERS="gcc-sanitizer"
SANITIZSERS_mips = ""

RDEPENDS_packagegroup_foo = "${SANITIZERS}"

(see the tools-profile packagegroup which does this heavily)

Ross

[-- Attachment #2: Type: text/html, Size: 1496 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3] libsanitizer: Enable GCC sanitizers
  2014-12-10 11:58             ` Burton, Ross
@ 2014-12-12  3:15               ` Dan McGregor
  0 siblings, 0 replies; 9+ messages in thread
From: Dan McGregor @ 2014-12-12  3:15 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Patches and discussions about the oe-core layer

On 10 December 2014 at 05:58, Burton, Ross <ross.burton@intel.com> wrote:
> Hi Dan,
>
> On 13 November 2014 at 23:35, Dan McGregor <danismostlikely@gmail.com>
> wrote:
>>
>> Looks like I needed to use the same security CFLAGS as gcc-runtime and
>> libgcc. There's a new version up on my bitbucket page.
>
>
> I see you're still using anonymous python instead of COMPATIBLE_HOST to mark
> what architectures the sanitizers work on, can you change that?
>
> For packagegroups, if my recollection is correct and the problem is that a
> packagegroup wants to depend on packages which are architecture-specific, a
> common trick is to do something like this:

Yeah, that was the problem. For this round I bit the bullet and made
the package group arch specific, and I got rid of the anonymous
python. I originally put that there so that it would parse the recipe
and not barf on arches where the sanitizer libraries are not
supported.

I think this looks better though, I was struggling with getting them
into a all arch package group.

>
> SANITIZERS="gcc-sanitizer"
> SANITIZSERS_mips = ""
>
> RDEPENDS_packagegroup_foo = "${SANITIZERS}"
>
> (see the tools-profile packagegroup which does this heavily)
>
> Ross


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-12-12  3:15 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-15  4:00 [PATCH v3] libsanitizer: Enable GCC sanitizers Dan McGregor
2014-09-15 15:00 ` Burton, Ross
2014-09-15 20:20   ` Dan McGregor
2014-09-15 20:28     ` Burton, Ross
2014-09-16 18:45       ` Dan McGregor
2014-11-04 13:45         ` Burton, Ross
2014-11-13 23:35           ` Dan McGregor
2014-12-10 11:58             ` Burton, Ross
2014-12-12  3:15               ` Dan McGregor

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.