Newest at the top
| 2024-05-02 18:25:01 +0200 | <tomsmeding> | I can compile an executable that gives the aforementioned string in file(1) output with just `-pie -dynamic`, nothing else |
| 2024-05-02 18:24:54 +0200 | <hseg> | tried --ghc-options='-pie -fPIE', didn't work |
| 2024-05-02 18:24:31 +0200 | <int-e> | s/--enable-shared/-fPIE/ I think (different from -pie, you need that for linking) |
| 2024-05-02 18:24:29 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 240 seconds) |
| 2024-05-02 18:23:50 +0200 | <hseg> | testing... |
| 2024-05-02 18:23:35 +0200 | <tomsmeding> | don't even need the --enable-shared |
| 2024-05-02 18:23:11 +0200 | <tomsmeding> | try cabal configure --enable-shared --ghc-options='-pie -dynamic' |
| 2024-05-02 18:23:01 +0200 | <tomsmeding> | hseg: is 'ELF 64-bit LSB pie executable' in file(1) output what you're looking for? |
| 2024-05-02 18:19:19 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-05-02 18:19:15 +0200 | yin | (~yin@user/zero) |
| 2024-05-02 18:19:07 +0200 | <hseg> | in any case, that does put pie and relro back on the table for me |
| 2024-05-02 18:17:50 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2024-05-02 18:17:03 +0200 | <hseg> | have they given up on ASLR for haskell? |
| 2024-05-02 18:16:54 +0200 | <hseg> | on dynamic linking, yes |
| 2024-05-02 18:15:49 +0200 | <tomsmeding> | debian has given up on that for haskell apparently https://wiki.debian.org/StaticLinking#Haskell |
| 2024-05-02 18:14:54 +0200 | <hseg> | nope -- PIC is for libraries, PIE is for executables AFAIK |
| 2024-05-02 18:14:51 +0200 | <tomsmeding> | despite the NOINLINE on foo in the source |
| 2024-05-02 18:14:42 +0200 | <tomsmeding> | about worker-wrapper, by the way: here https://play.haskell.org/saved/yjnPTDnN if you click on "Core" you see 'foo' at the bottom with annotations that say that it can be inlined; the NOINLINE is on M.$wfoo right above |
| 2024-05-02 18:14:26 +0200 | califax | (~califax@user/califx) |
| 2024-05-02 18:13:54 +0200 | <tomsmeding> | isn't an executable already PIE if it's dynamically linking against stuff? |
| 2024-05-02 18:13:22 +0200 | <hseg> | (and relro, but that's a separate thing) |
| 2024-05-02 18:13:08 +0200 | <hseg> | right, but that means that even statically-linked haskell should benefit from -pie |
| 2024-05-02 18:12:48 +0200 | <tomsmeding> | haskell executables do link dynamically against C libraries though |
| 2024-05-02 18:12:41 +0200 | <EvanR> | randomly clicking utf8-string on that page makes me think there should be a note about how Text is utf8 now |
| 2024-05-02 18:12:30 +0200 | <tomsmeding> | I guess? I don't know too much about this |
| 2024-05-02 18:12:20 +0200 | <hseg> | after all, it enables ASLR |
| 2024-05-02 18:12:06 +0200 | <hseg> | wait, isn't *PIC* for dynamic libraries, but *PIE* for any executable? |
| 2024-05-02 18:11:32 +0200 | <tomsmeding> | (random page with the name on it) |
| 2024-05-02 18:11:23 +0200 | <tomsmeding> | EvanR: makes me think of this guy's name https://hackage.haskell.org/user/IanLynagh |
| 2024-05-02 18:10:21 +0200 | <hseg> | right |
| 2024-05-02 18:10:14 +0200 | <tomsmeding> | it probably doesn't for the standard reasons why builds are not reproducible, timestamps, paths etc |
| 2024-05-02 18:09:50 +0200 | <tomsmeding> | same code with same compiler and same flags could, in principle, produce the same object code |
| 2024-05-02 18:09:31 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-05-02 18:09:24 +0200 | <tomsmeding> | indeed |
| 2024-05-02 18:09:13 +0200 | <hseg> | just realized -- this has nothing to do with reproducible builds, that is something GHC *could* theoretically guarantee (and that is something that's more desireable to me) |
| 2024-05-02 18:08:52 +0200 | <tomsmeding> | question is whether it would be worth the effort and the potential loss of some performance (to be measured) |
| 2024-05-02 18:08:37 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-05-02 18:08:36 +0200 | <EvanR> | IANAGH |
| 2024-05-02 18:08:31 +0200 | <tomsmeding> | but compiling a standardised wrapper function would theoretically be possible always |
| 2024-05-02 18:08:22 +0200 | <hseg> | fair enough |
| 2024-05-02 18:08:07 +0200 | <tomsmeding> | there may well me more reasons for ABI instability that I'm not aware of -- I'm not a ghc hacker |
| 2024-05-02 18:07:54 +0200 | <tomsmeding> | worker-wrapper is one thing I know of where this plays a role |
| 2024-05-02 18:07:45 +0200 | <tomsmeding> | indeed |
| 2024-05-02 18:07:40 +0200 | <hseg> | right, because now the workers will be opaque |
| 2024-05-02 18:07:25 +0200 | <tomsmeding> | yes |
| 2024-05-02 18:07:23 +0200 | <hseg> | but wouldn't that lose optimization opportunities? |
| 2024-05-02 18:07:17 +0200 | <tomsmeding> | conceptually this isn't very difficult, but it would be a lot of engineering |
| 2024-05-02 18:07:03 +0200 | <tomsmeding> | then you'd have to convince GHC to use those wrappers instead of the workers directly |
| 2024-05-02 18:06:49 +0200 | <tomsmeding> | you'd have to define some standard calling convention, and use that to define additional wrapper functions that _are_ materialised in the object files, and just unused whenever GHC can see the interface file |
| 2024-05-02 18:06:20 +0200 | <tomsmeding> | I mean, it wouldn't be that hard |