On Thu, Sep 16, 2021 at 3:52 PM Iain Sandoe <i...@sandoe.co.uk> wrote: > > > Hi Martin, > > > 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. 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. So for this alternate assembler file we'd have a different set of sections. > — > > (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 ;) > > 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) > > --- > > /src-local/gcc-master/gcc/dwarf2asm.c: In function ‘void > dw2_asm_output_nstring(const char*, size_t, const char*, ...)’: > /src-local/gcc-master/gcc/output.h:387:26: error: expected initializer before > ‘->’ token > #define asm_out_file casm->out_file > ^ > /src-local/gcc-master/gcc/defaults.h:68:13: note: in expansion of macro > ‘asm_out_file’ > FILE *asm_out_file = _hide_asm_out_file; \ > ^~~~~~~~~~~~ > /src-local/gcc-master/gcc/dwarf2asm.c:414:7: note: in expansion of macro > ‘ASM_OUTPUT_ASCII’ > ASM_OUTPUT_ASCII (asm_out_file, str, len); > ^~~~~~~~~~~~~~~~ > In file included from ./tm.h:42:0, > > ------ > > /src-local/gcc-master/gcc/config/i386/darwin.h:219:6: error: ‘in_section’ was > not declared in this scope > if (in_section == text_section) \ > ^ > /src-local/gcc-master/gcc/dwarf2out.c:677:3: note: in expansion of macro > ‘ASM_OUTPUT_ALIGN’ > ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (PTR_SIZE)); > >
