diff options
| author | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2024-08-01 00:57:37 +0200 |
|---|---|---|
| committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2024-08-01 00:57:37 +0200 |
| commit | 4ff7a6c4a504a7801bd33221fa56cdfa7f87ccdc (patch) | |
| tree | faef27573728f3389f2cebb8af0ce871979abc83 /open_issues/_san.mdwn | |
| parent | abdefb07cfe378c57fcc2995aa88d11f4c6976e0 (diff) | |
Diffstat (limited to 'open_issues/_san.mdwn')
| -rw-r--r-- | open_issues/_san.mdwn | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/open_issues/_san.mdwn b/open_issues/_san.mdwn index d514cfb2..374e89fe 100644 --- a/open_issues/_san.mdwn +++ b/open_issues/_san.mdwn @@ -35,11 +35,12 @@ as: * Undefined Behavior Sanitizer (UBsan; `-fsanitize=undefined`) Porting these to the Hurd is not a trivial task, for they have intimate -knowledge about the operating system kernel they're running on, and from a -first look they reimplement a lot of [[/glibc]] by directly using +knowledge about the operating system kernel they're running on, and +reimplement the needed parts of [[/glibc]] by directly using [[system_call]]s -- which is basically a no-go on GNU Hurd. -Samuel took some look at it and got some basic support for libubsan and libasan: +Samuel took some look at it and got some basic support for libubsan and libasan +by making it call glibc still: <https://people.debian.org/~sthibault/hurd-i386/libubsan-hurd.diff> which allowed to fix some issues in the hurd code. |