[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

["gjl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

--- Comment #13 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Matthijs Kooijman from comment #12)
> Apologies if this is an obvious question, but I'm not familiar with gcc/g++
> internals. Georg-Johann, you say this requires address space support in c++,
> but I'm not sure I follow you there. Two things:
> You say WG21 will never add AS support to C++, but also say that language
> support for AS is not needed, only internal support in gcc/g++. So that
> means what WG21 does is not relevant for vtable handling in particular?

Front-end maintainers usually follow the WGs in what they implement and are
willing to approve.  When you propose some non-standard extensions — even as a
working patch with testcases, documentation, etc. — the maintainers will reject
it.  They fear it might be inconsistent with existing features or the code
"just being dropped" and maintenance burden is up to them.

Adding AS in the c++ front-end without exposing them to the language (i.e. you
still can't use __flash in c++) will be rejected by the maintainers as "too
specific", see below for similar case.

> Even if AS would not be used, what prevents g++ from emitting the vtables
> in the `progmem.data` section and generating vtable-invocation code using
> LPM instructions?

vtables are generated by the c++ front-end.  Some hacking in the avr back-end
might be enough to but these tables in flash, but you cannot access it
correctly without qualifying all accesses.  These qualifiers must be added by
the c++ FE so that any pointers / accesses / (internal) variables derived from
it use the correct AS.

We just saw the maintainers rejecting PR49857 (which is about putting
tree-switch-converted lookup-tables into flash / named AS) as "too specific". 
The avr part was approved.  The only change to the middle-end was a well
documented hook (statically) invoked only once in tree-switch-conversion
module.  The maintainers proposed "more generic" solution; none of proposals
would work and none of them would be more generic because the only object
that's opt to such optimization is CSWTCH from tree-switch-conversion.

I got the impression it wasn't even understood why one cannot just patch
sections.  And patching ASes won't work if any pass might copy a pointer. The
tables must be read-only, in static storage, not public, not weak, not
linkonce, not comdat, and must be artificial, i.e. cooked up by the compiler
(otherwise inline asm will break).  So the only use case was CSWTCH anyway...

For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857#c17

vtables are even more restrictive because it would be an ABI change: all
modules accessing the vtable must agree upon it's AS, i.e. you cannot specify
the AS per command option.

> or some gcc-specific attribute on a class?

Attributes won't work — due to the same reason for why progmem does not work
with c / c++: with progmem: you'd need inline asm.  And because vtables are
artificial, you'll never gat a hand on them.

And to be honest:  My current impression is that avr-gcc is a dead horse. 
http://gcc.gnu.org/ml/gcc/2017-07/msg00224.html

Maintainers are proposing to deprecate bunch of backends as a side effect of
deprecating two essential features that are "old code" and not used by the
targets they get their bucks for.  Sooner or later they will succeed,
effectively throwing bunch of targets into the dust bin.

With that perspective and my recent impressions, I think working on avr-gcc has
become a waste of time.