| 8 Feb 2024 |
 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 | 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 | 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 |
| raitobezarius | this should be benchmarked then | 18:15:45 |
| aloisw | I now remember this does not actually seem to be the case. The profiler frontend I use (Hotspot) is unable to augment the frame pointer data with debug info data. | 18:30:46 |
| aloisw | One of the reasons I use DWARF-based unwinding. | 18:31:10 |
| aloisw | But take my statements about profiling with a grain of salt in general, my use case is very specific (single-process, deterministic, CPU (or swap) bound). | 18:32:33 |
 trofi | Default strip hook removes dwarf data, but not the symbols themselves. nixpkgs packages have almost all the symbols in all binaries and libraries. | 19:57:43 |
| trofi | That 's for example why perf top reports all it's own symbols when it dies (instead of reporting just addresssssssses) :)
$ perf top -a
perf: Segmentation fault
-------- backtrace --------
/run/current-system/sw/bin/perf[0x626d62]
/nix/store/7jiqcrg061xi5clniy7z5pvkc4jiaqav-glibc-2.38-27/lib/libc.so.6(+0x3deb0)[0x7fe05da54eb0]
/run/current-system/sw/bin/perf(__dsos__findnew_link_by_longname_id+0x34b)[0x53633b]
/run/current-system/sw/bin/perf(map__new+0x35f)[0x55867f]
/run/current-system/sw/bin/perf(machine__process_mmap2_event+0xb7)[0x557957]
/run/current-system/sw/bin/perf(perf_tool__process_synth_event+0x7e)[0x59e3ee]
/run/current-system/sw/bin/perf(perf_event__synthesize_mmap_events+0x369)[0x59ec59]
/run/current-system/sw/bin/perf[0x59f8dc]
/run/current-system/sw/bin/perf[0x59fb4c]
/run/current-system/sw/bin/perf[0x59fc13]
/nix/store/7jiqcrg061xi5clniy7z5pvkc4jiaqav-glibc-2.38-27/lib/libc.so.6(+0x8b333)[0x7fe05daa2333]
/nix/store/7jiqcrg061xi5clniy7z5pvkc4jiaqav-glibc-2.38-27/lib/libc.so.6(+0x10defc)[0x7fe05db24efc]
| 19:59:59 |
| trofi | (Oh, and perf crash is a gcc bug, I completely forgot that the fix was not yet backported to gcc-13 branch: https://gcc.gnu.org/PR111009) | 20:19:31 |
| trofi | * (Oh, and perf crash is a gcc bug, I completely forgot that the fix was not yet backported to gcc-13 branch: https://gcc.gnu.org/PR111009; Proposed the workaround as https://github.com/NixOS/nixpkgs/pull/287310 ) | 20:54:49 |
| trofi | binutils: 2.40 -> 2.41 update is ready for review (not sure if we need a hydra run against the branch before the merge): https://github.com/NixOS/nixpkgs/pull/283732 | 22:57:28 |
| 9 Feb 2024 |
 Philip Taron (UTC-8) | In reply to @trofi:matrix.org
binutils: 2.40 -> 2.41 update is ready for review (not sure if we need a hydra run against the branch before the merge): https://github.com/NixOS/nixpkgs/pull/283732 What sort of review would you like, trofi ? I looked through the set of changes and they do what they say on the tin. | 17:24:23 |
| trofi | In reply to @philiptaron:matrix.org
What sort of review would you like, trofi ? I looked through the set of changes and they do what they say on the tin. I wonder if we should request a one-off hydra jobset or people confident it's already good enough and we should push it to staging ~as is. | 20:44:13 |
| Philip Taron (UTC-8) | I'd send it. | 20:48:55 |
| Philip Taron (UTC-8) | Gave it the old ✅ for whatever that's worth. | 21:01:15 |
| 11 Feb 2024 |
 Puna | In reply to @opna2608:matrix.org
anyone who could give https://github.com/NixOS/nixpkgs/pull/255451 a look, maybe even someone who could upload the files to tarballs.nixos.org 👀? anyone? i'm not sure if this is just missing something that nobody's communicating to me, or if the ppl i pinged on it just don't have the time to look at it. | 18:11:19 |
| 12 Feb 2024 |
| trofi | I wrote the maintainers/scripts/bootstrap-files/README.md recently. That might help you. | 00:33:05 |
| trofi | * I wrote the https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/bootstrap-files/README.md recently. That might help you. | 00:33:55 |
| Puna | that seems to talk about updating existing bootstrap-files via already present hydra jobs, i'm trying to add new bootstrap-files with no matching hydra job | 06:43:04 |
| Puna | and the file that defines those targets for hydra now has a comment seemingly asking ppl to not add new targets unless there's already a matching bootstrap-files entry for it. but both of those seem to require each other first, so i'm not sure what the intended procedure is supposed to be for this anymore | 06:51:33 |
| trofi | Ah, ok. I would expect hydra cross-job submission to be the first step before creation of boothstap-files. | 07:16:28 |
| trofi | * Ah, ok. I would expect hydra cross-job submission to be the first step before upload request of bootstrap-files. | 07:19:04 |
| Puna | so would i, but that doesn't seem to be compatible with NOTE: Only add platforms for which there are files in './bootstrap-files'. | 08:03:24 |
| Puna | and the powerpc64 entry that already existed there was cleaned up because of that | 08:06:41 |
