lto: from insert_attributes to file_end?

[Georg-Johann Lay]

Am 06.05.26 um 09:51 schrieb Richard Biener:
> On Tue, May 5, 2026 at 8:16 PM Georg-Johann Lay <avr@gjlay.de> wrote:
>> Am 05.05.26 um 19:05 schrieb Richard Biener:
>>> On Tue, May 5, 2026 at 5:41 PM Georg-Johann Lay via Gcc <gcc@gcc.gnu.org> wrote:
>>>>
>>>> In the avr backend there is a static variable avr_no_call_main_p that
>>>> is set in TARGET_INSERT_ATTRIBUTES and used in TARGET_ASM_FILE_END.
>>>>
>>>> This works as expected in non-LTO compilations, with LTO however,
>>>> TARGET_INSERT_ATTRIBUTES runs in cc1[plus] but TARGET_ASM_FILE_END
>>>> is run by lto1, hence the variable is not set as expected.
>>>>
>>>> What's the recommended way to handle such a situation?
>>>
>>> Without looking too closely I assume there's an actual attribute somewhere
>>> (on the main function decl?).  Instead of using a global variable you'd
>>> check for the presence of the attribute.  Now - the question is whether
>>> the TARGET_ASM_FILE_END behavior is only required in the TU with
>>> the main() definition?  In that case this should work.
>>
>> What works is to attach a new attribute to main when the conditions are
>> right, then check for that attribute in, say,
>> TARGET_DECLARE_FUNCTION_NAME and set a variable accordingly, and then
>> check for that var in TARGET_ASM_FILE_END.
> 
> It's not technically required to be handled from TARGET_ASM_FILE_END,
> correct?

Exactly.  Background: main is called by __call_main which is provided
by some default lib*.a.  It is referenced by crt*.o to pull it in.

With -mno-call-main, main is effectively a part of the startup-code.
The application emits
    .global __call_main
    __call_main = 0
so __call_main it is no more pulled in since it is no more needed.

 > It should work to emit the symbol from ASM_OUTPUT_FUNCTION_LABEL?> 
(not sure if there's sth more appropriate for 'before function' or
> 'after function')  You'd at least have access to the functions decl there.

Using a new attribute and emit .global __call_main + __call_main=0 in
ASM_OUTPUT_FUNCTION_LABEL (or TARGET_ASM_FILE END) generates code as
expected, however I am getting an error from the linker because
__call_main is defined in lib*.a and also in some app module.

What works fine is adding  %{mno-call-main: --defsym __call_main=0}
to the link specs, and skip messing with __call_main in avr.cc
altogether.  See attached delta.

When the user sets -mcall-main as well as -mno-call-main in the same
app, then it's fine for me it that doesn't work.

Johann

>> What's a bit ugly is that it requires a new target attribute that's only
>> for internal usage and should not to be set by the user.  Maybe not
>> document it is okay then.
> 
> As Sam says, an attribute with a space cannot be used by users.  Like
> "avr no_call_main".
> 
> But also see the PR iff the only way for the user to get the behavior
> with -mno-call-main
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr125194-v2.diff
Type: text/x-patch
Size: 2949 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20260506/5faa73dd/attachment.bin>