Georg-Johann Lay <a...@gjlay.de> writes: > Am 24.01.25 um 08:18 schrieb Richard Biener: >> On Thu, Jan 23, 2025 at 4:53 PM Georg-Johann Lay <a...@gjlay.de> wrote: >>> >>> Am 23.01.25 um 14:58 schrieb Richard Biener: >>>> On Thu, Jan 23, 2025 at 2:23 PM Georg-Johann Lay <a...@gjlay.de> wrote: >>>>> >>>>> Hi, this is Ping #2 for a patch from 2024. >>>>> >>>>> It adds a new target hook that allows to output >>>>> assembly code for a VAR_DECL in a custom way. >>>>> >>>>> The default action is an obvious no-op, >>>>> i.e. assemble_variable() behaves like before. >>>> >>>> I tried to understand the AVR part of the series - there I fail to see >>>> what exactly special handling "io" and friends requires and how >>>> that was made work with the TLS noswitch section. >>>> >>>> I do not think the sentence the middle-end doesn't allow custom >>>> NOSWITCH sections is correct (it would be a matter of exporting >>>> get_noswitch_section), but I also don't exactly see how >>>> "io" and friends require a NOSWITCH. >>> >>> A noswitch section is one way to go. >>> >>> However, there is no way to attach a noswitch section to a VAR_DECL. >> >> Hmm, I don't know varasm.cc by heart either but there's the select_section >> hook invoked by get_variable_section () which looks like it could do the >> trick. > > No. > > That hook only returns a section *name*, not a section object. > So you cannot return an unnamed section, which by definition, don't > have a section name.
Perhaps I misunderstand what you mean, but select_section does return a "section *". On the point about -fdata-sections, I think avr's unique_section should be a no-op for these variables. That should ensure that the compiler doesn't set DECL_SECTION_NAME itself. (I suppose that source-code attributes that set DECL_SECTION_NAME should be diagnosed as incompatible with the io attribute.) FWIW, I agree with Richard that a hook to bypass most of assemble_variable doesn't feel like the right abstraction. Thanks, Richard
