In reply to @emilazy:matrix.org
Alyssa Ross: was the review request of Ericson2314 and lovesegfault after the approvals on the VC4 PR intentional or just GitHub stuff?

In reply to @luckytethys:matrix.org

Alyssa Ross: If you want I can try to see if I can add support for using those multi-arch-aware versions in upstream pwntools -- but honestly the code is already pretty convoluted and I am having a bit of a hard time making heads or tails in it.

I don't know exactly what flags I would need to add to e.g. get the multi-arch-aware objcopy to work with pwntools, and whether those options also be compatible with the non-multi-arch version.

In reply to @luckytethys:matrix.org

Alyssa Ross: If you want I can try to see if I can add support for using those multi-arch-aware versions in upstream pwntools -- but honestly the code is already pretty convoluted and I am having a bit of a hard time making heads or tails in it.

I don't know exactly what flags I would need to add to e.g. get the multi-arch-aware objcopy to work with pwntools, and whether those options also be compatible with the non-multi-arch version.

In reply to @qyliss:fairydust.space
I think it would be nice if we didn't have to duplicate functionality from binutils-unwrapped-all-targets, and just have gas packages for the different architectures. If it ends up being infeasible then we can probably make multiple binutils packages work, but I think it would be much better not to now that I know binutils-unwrapped-all-targets exists.

Most of the code is 5-10 years old. ~60% written by a previous maintainer who's now deceased, ~20% written by current maintainers, ~10% written by me (all of it in 2014). It's a lot of "if it ain't broken, don't fix it" code.

I can give it a shot, but I am not sure if the current maintainers would be that happy to accept the patches

In reply to @emilazy:matrix.org
it doesn't seem like it should be disproportionately more maintenance effort to build the objdumps, right? I guess ld.bfd might be another story

Right, but then we have stuff duplicated by packages, and it's also unclear then what these packages even are. Some but not all of binutils? If they're just gas that's a lot clearer.

In reply to @luckytethys:matrix.org

Most of the code is 5-10 years old. ~60% written by a previous maintainer who's now deceased, ~20% written by current maintainers, ~10% written by me (all of it in 2014). It's a lot of "if it ain't broken, don't fix it" code.

I can give it a shot, but I am not sure if the current maintainers would be that happy to accept the patches

In reply to @qyliss:fairydust.space
We could patch in Nixpkgs — probably makes more sense than tailoring our packages to pwntools' needs specifically rather than based on binutils' actual capabilities.

In reply to @emilazy:matrix.org
it could just be all of binutils :) I feel like having an override for the binutils target that just works would be nice in general

In reply to @emilazy:matrix.org
like, there's going to be more software that just wants a conventional single-target binutils for a certain target, I imagine. embedded stuff or the like.

In reply to @luckytethys:matrix.org
Hmm, the derivation also uses a lot of other information from targetPlatform, like isAvr and isWindows. Should I try to create an object that matches the targetPlatform format? Isn't that almost as bad as my original approach?

emily

In reply to @emilazy:matrix.org
maybe the all-targets binutils should just build all the ases. I guess that might make the derivation awkward though.

In reply to @luckytethys:matrix.org
Oh, in that case it would be a lot easier. That might be feasible.

In reply to @qyliss:fairydust.space
I believe it'll build an as for targetPlatform