Hi Richard, > On 26 Oct 2023, at 21:00, Iain Sandoe wrote: >> On 26 Oct 2023, at 20:49, Richard Sandiford wrote: >> >> Iain Sandoe writes: >>> This was written before Thomas' modification to the ELF-handling to allow >>> a config-based change for target details. I did consider updating this >>> to try and use that scheme, but I think that it would sit a little >>> awkwardly, since there are some differences in the start-up scanning for >>> Mach-O. I would say that in all probability we could improve things but >>> I'd like to put this forward as a well-tested initial implementation. >> >> Sorry, I would prefer to extend the existing function instead. >> E.g. there's already some divergence between the Mach-O version >> and the default version, in that the Mach-O version doesn't print >> verbose messages. I also don't think that the current default code >> is so watertight that it'll never need to be updated in future. > > Fair enough, will explore what can be done (as I recall last I looked the > primary difference was in the initial start-up scan). I’ve done this as attached. For the record, when doing it, it gave rise to the same misgivings that led to the separate implementation before. * as we add formats and uncover asm oddities, they all need to be handled in one set of code, IMO it could be come quite convoluted. * now making a change to the MACH-O code, means I have to check I did not inadvertently break ELF (and likewise, in theory, an ELF change should check MACH-O, but many folks do/can not do that). Maybe there’s some half-way-house where code can usefully be shared without those down-sides. Anyway, to make progress, is the revised version OK for trunk? (tested on aarch64-linux and aarch64-darwin). thanks Iain