Re: error linking lto1 for target avr

[Ian Lance Taylor <iant at google dot com>]

Georg-Johann Lay <avr@gjlay.de> writes:

> Ian Lance Taylor wrote:
>
>> Georg-Johann Lay writes:
>> 
>>> Suppose avr.c:avr_out_lpm which is used to print insns in final,
>>> e.g. ADJUST_INSN_LENGTH.
>>>
>>> Should avr_out_lpm be moved to avr-c.c? And avr-c.c include all the
>>> rtl.h, tree.h, output.h etc. which is also needed by the functions
>>> that like to use c_addr_space_name?
>> 
>> It's fine for avr-c.c to include rtl.h, tree.h, etc. (though including
>> tree.h is unusual).  It's fine for avr-c.c to call functions in avr.c.
>
> I need it the other way round: With a wrapper for c_addr_space_name located in
> avr-c.c that wrapper (or any other code moved to avr-c.c) needs to be called
> from avr.c.  Is that ok?  If the answer is "yes": I don't quite understand why
> that works and at what stage the otherwise missing function/object is dragged
> in. If the answer is "no": This means I have to copy-paste the code from
> c-common to avr.c? If such hack is actually needed, there must be a design flaw
> somewhere.

The problem is straightforward if you stop and think about it.  The code
in c-family is only available in the C and C++ frontends (and Objective
C and Objective C++).  When using LTO, neither the C nor the C++
frontend is linked into the binary.  When using LTO, you can not call a
function which only exists in the C or C++ frontend.

The point of avr-c.c is for it to provide functions which are only used
with the C and C++ frontends.  You can't call from avr.c to avr-c.c.
That would just be the same problem in a different form.

Copying the function c_addr_space_name to avr.c won't work either.  That
function needs to know information that only exists in the C and C++
frontends.

>> The point is that functions that are C/C++ specific need to not be in
>> avr.c, because they will break for languages other than C/C++.  In this
>> terminology, LTO counts as a language.
>> 
>>> Is is legitimate to use MEM_ADDR_SPACE in avr.c?
>> 
>> Yes.
>
> Again I don't understand.  MEM_ADDR_SPACE does not make sense when compiling
> Ada, say. I'd guess XXX_ADDR_SPACE are just accessors for fields in tree or rtx
> that are reserved by the C front end.  How do I know that the Ada front end
> does not reserve these bits for different purpose so that using the accessors
> get funny results?

MEM_ADDR_SPACE is defined generically.  You can see it in rtl.h.  Any
frontend can create and use address spaces.

> Moreover, I don't get the difference between c_addr_space_name on the one side
> and MEM_ADDR_SPACE, TYPE_ADDR_SPACE, ADDR_SPACE_GENERIC and addr_space_t on the
> other side.  I mean on the conceptual level, not on the technical
> (macro/function/typedef) level.

c_addr_space_name corresponds to c_register_addr_space.  This is
distinct from addr_space_t and friends.  Any frontend can define values
for addr_space_t.  The C/C++ frontends happen to permit the backend to
define such values via c_register_addr_space.

> They all make sense in C only, not even in C++ because named addresses are not
> available in C++.

That is not a fundamental limitation, just a statement about what the
various frontends currently implement.


The current code in avr.c is only calling c_addr_space_name to get the
name for an addr_space_t.  You already have a mapping from address space
names to addr_space_t values in avr_register_target_pragmas in avr-c.c.
Just move that into a table in avr.c and use that table rather than
c_addr_space_name.


Ian