On Fri, Oct 27, 2023 at 4:00 AM Iain Sandoe <i...@sandoe.co.uk> wrote: > > Hi Richard, > > > On 26 Oct 2023, at 21:00, Iain Sandoe <i...@sandoe.co.uk> wrote: > > >> On 26 Oct 2023, at 20:49, Richard Sandiford <richard.sandif...@arm.com> > >> wrote: > >> > >> Iain Sandoe <iains....@gmail.com> 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.
There is already gcc.test-framework which seems like a good place to put a test for both formats so when someone changes the function, they could run that testsuite to make sure it is still working for the other format. (Note I am not saying you should add it as part of this patch but it seems like that would be the perfect place for it.) Thanks, Andrew > > Anyway, to make progress, is the revised version OK for trunk? (tested on > aarch64-linux and aarch64-darwin). > thanks > Iain > > >
