| 6 Feb 2024 |
 Sandro 🐧 | ohhh 🤔 | 18:31:13 |
 trofi | tpm2-tss overrides read(), but not read64(). File offset bits just break it's build. | 19:18:08 |
| trofi | https://github.com/tpm2-software/tpm2-tss/blob/e637b842322b1a64f9ad10af66af43d2d9328564/test/unit/tcti-device.c#L153 | 19:23:14 |
| trofi | As it goes via "-Wl,-wrap" linker hack it completely bypasses "#define read read64". | 19:24:55 |
| trofi | I would expect binary packages in less of a danger (unless there are common libraries that export unsized "off_t" and friends) | 19:26:11 |
| trofi | * tpm2-tss overrides read(), but not read64(). File offset bits just break it's tests as overrides does not happen any more. | 19:30:56 |
| 7 Feb 2024 |
|  Sean Link set a profile picture. | 20:08:43 |
| 8 Feb 2024 |
 raitobezarius | does anyone has an opinion on enabling frame pointers by default? | 16:04:15 |
| raitobezarius | I have been thinking about it for a while and Jon Seager told me about it recently and talked about it recently: https://fosdem.org/2024/events/attachments/fosdem-2024-3513-what-s-possible-in-observability-when-we-have-frame-pointers/slides/22782/2024-02_-_FOSDEM_-_frame_pointers_xaPhw1N.pdf | 16:04:42 |
| trofi | nixpkgs does not seem to focus on producing fast binaries anyway (-fPIC, -fstack-protector-strong, -fno-strict-overflow and more to be added by default: all are stealing bytes on stack, registers to manage and inxtra instructions to handle by CPU), thus might be fine :) | 16:17:57 |
| raitobezarius | neat :-) | 16:18:46 |
| raitobezarius | is it just a matter of inserting -fno-omit-frame-pointer in the stdenv, right? | 16:18:59 |
| trofi | Yeah | 16:20:00 |
| trofi | Better guard it behind an off-switch to be able to repare rare users that expect inlining and sibling call optimizations to work (like glibc early ld.so code or linux kernel's boot code). | 16:21:09 |
 @aloisw:kde.org | There already is https://github.com/NixOS/nixpkgs/pull/216341 btw | 18:04:02 |
| raitobezarius | yeah but it's not doing the change in cc-wrapper | 18:04:56 |
| @aloisw:kde.org | It should probably also be discussed how useful frame pointers are when the debug symbols have already been lost, as is seemingly very common. | 18:05:23 |
| raitobezarius | well i wouldn't make frame pointers dependent on debug symbols | 18:09:43 |
| raitobezarius | we can make frame pointers now | 18:09:49 |
| raitobezarius | and still work towards dsyms no? | 18:09:53 |
| @aloisw:kde.org | I wasn't saying frame pointers are useless without debug info, you can probably still get some results from the symbol table alone. | 18:12:19 |
| raitobezarius | right I'm not saying you said that | 18:12:30 |
| raitobezarius | I'm not sure the discussion about usefulness without dsyms is important to make the change | 18:12:47 |
| @aloisw:kde.org | But frame pointers have a cost, and their benefit is at least somewhat reduced without debug info. | 18:12:54 |
| raitobezarius | right | 18:15:39 |
