Hi Folks, > On 17 Sep 2021, at 09:23, Richard Biener <richard.guent...@gmail.com> wrote: > > On Thu, Sep 16, 2021 at 3:52 PM Iain Sandoe <i...@sandoe.co.uk> wrote: >> >> >>> On 16 Sep 2021, at 11:00, Martin Liška <mli...@suse.cz> wrote: >>> >>> As preparation for a new global object that will encapsulate >>> asm_out_file, we would need to live with a macro that will >>> define asm_out_file as casm->out_file and thus the name >>> can't be used in function arguments. >> >> So, if I understand correctly, the motivation is to be able to switch >> between output file streams for different categories of content? >> >> Darwin, actually already does this (manually) with a separate >> lto_asm_out_name for lto data (so a general solution would >> be great). >> >> What is the reason for associating the section pointers with the >> casm object? >> >> * I can understand that each instance of a casm object would have >> potentially a different current section (“in_section”), but it seems that >> as things stand the section pointers would be duplicates. >> >> * In the case that there’s reason that the sections could be different >> between casm instances, then would it make sense to have a >> target hook so that target-specific sections can be added to the >> local list (via some indirection, I’d assume)? > > Yes, casm likely will end up with target specific state. Note the main > motivation of the exercise is to develop and alternate way of funneling > the early debug data through the LTO pipeline, eliding the need for > the simple-object copying and section renaming dance.
great ;-) FWIW, I did an implementation for Darwin, but not yet presented/comitted because…. the dependencies on the debug linker (dsymutil) mean that it is of limited value until I can find time to fix that up to understand the input. > The idea is that at dwarf2out_early_finish time (which runs at > the compile stage) we write a regular pure debug-info object > with unmangled section names to an alternate assembler file > which we then assemble and include as raw byte blob in the > LTO IR + debug object file. At link time the debug object > byte blobs can either be re-instantiated as separate input > object file or the linker can be taught to pick them up from > the existing file at a byte offset (internally it does this for > AR archive members for example) avoiding the extra I/O. … the more dependencies on external tool behaviour we have the harder it gets for non-ELF-binutils targets; I’d like to think about how to implement this in Mach-O… I don’t think there’s any mechanism for Mach-O to include an arbitrary blob in a _regular_ mach-o file, of course one could make it FAT in some way - but that would mean a lot of changes to the back end tools.. … so the path of least resistance is to do something like we do with the LTO already - abstract the info into a blob section with and index and a name table (we funnel the LTO off into a second file and then re-include that in finish_asm_file). not sure what xcoff etc. can do... > So for this alternate assembler file we'd have a different set > of sections. can you give me an example ? (I’m not succeeding in visualizing this yet). Note that we already have categories of sections: generic (e.g. .text, .data, etc. supported by all file formats) language-related (for at least C++, D, ObjC…) debug lto back-end-specific I was wondering which of those needed to be cloned per casm and if it includes any of the language/back-end ones how we figure a mechanism to include those (I suppose the usual style of a macro- programmed .def would work?) >> — >> >> (of course, it would be great if one day we could abstract the asm out >> such that we could switch to a direct-to-object implementation) > > Small steps ;) Yes - but it’s easier to see if the small steps are in the direction we want, with some idea of the finishing post, right? :) I was wondering about a conceptual scenario like: casm ==> target_asm state this also conceptually “owns” the TARGET_ASM macros. one could consider migrating those macros to add casm as a first argument this would allow a second migration when target chose to implement the macros as inline functions taking the state as a first argument... .. or to implement casm as an abstract base class, where the target macros become virtual methods, with a default impl. that can be overriden by the target. My guess is that people will say “the second one is too much overhead because it incurs an indirection instead of the direct inline” … I suppose that depends on how well we devirtualize …. >>> I've built all cross compilers with the change and >>> can bootstrap on x86_64-linux-gnu and survives regression tests. >> >> A native bootstrap fails early in stage1 for x86_64-darwin (I’ll take a look >> at fixing the issues once the patch series settles down) JFTR, I applied the first two patches and then a couple of tweaks and it did bootstrap on Darwin. thanks Iain
