Heren, dank voor de suggesties. Eric: die volgorde veranderen had ik ook al bedacht, maar ik moet hem nog uitvoeren. Je hebt gelijk dat het voor de praktijk niet zinnig is om het zo te doen, maar daar zijn we niet mee bezig: We zijn een fout aan het zoeken. Dus: Prima suggestie.
Done: Met de assignment VOOR de memset krijg ik weer de grote binary. (ik ben nu niet bij de hardware, toen ik dat wel was keek ik naar de programmer die zei: 14k geprogrammeerd, klaar! Het compileer proces zonder programmeren geeft ook een rapportje en dat gebruik ik nu.
Elmo: Ik hou niet van warnings, dus normaliter zal ik niet rusten voordat alle warnings er uit zijn.... Hier ben ik lui geweest en er zitten nu een paar warnings in dit project. Dank voor de "push" om even door te bijten en aan de warnings te werken. Hij is nu clean.
Nog een kleinigheidje: Ik krijg nog een warning:
en op het eerste gezicht klinkt dat relevant. 
Het gaat over een debug structure die buiten de hele normale code-flow om data van 1 deel van de code naar een ander deel brengt om dat ene ding te kunnen debuggen.
Ik heb:
struct pkt_dbg {
int len;
data[256];
};
struct pkt_dbg odbg, idbg;
toegevoegd in de code die met de packets hoort te spelen.
Vervolgens in mijn code waar ik dat kan printen heb ik: (omdat ik niet zomaar een "gezamelijke include" kon vinden waar ik dat netjes in kon zetten... ) gewoon de struct opnieuw gedeclareerd (copy-paste) en extern voor de variabele declaratie gezet.
cmds.c:701:29: warning: type of 'idbg' does not match original declaration [-Wlto-type-mismatch]
701 | extern struct pkt_dbg odbg, idbg;
Deze warning komt uit de LTO optmizer. De declaraties zijn identiek, maar zou ie "gedeclareerd op regel XX van file YY" meenemen in de "is ie identiek?" beslissing?
Goed.... Dat nu ook opgelost. Extra include aan "niet-mijn-code" toegevoegd, en aan mijn code waar ik de declaratie gedupliceerd had, nu vind ie die declaraties wel gelijk en krijg ik die warning niet meer.
Het goede nieuws: Nu geen enkele warning meer in het hele project.
Het slechte nieuws: nog steeds 60k code zoek als de assignment achter de memset staat.
Blurp: Met LTO uit, krijg ik een binary van 15k: Kan ook niet kloppen. met -O2 veranderd in -Os wordt ie 13k. Met -O0 wordt ie 120k.
Als ik "tot in assembly" compileer, dan compileert de memset tot:
.LVL94:
.loc 1 539 3 view .LVU475
.loc 1 540 3 view .LVU476
.loc 1 540 22 is_stmt 0 view .LVU477
movs r3, #0
strb r3, [r3]
.inst 0xdeff
.L130:
En direct daarachter staat iets met "endproc" en geen code meer voor de rest van m'n "main" functie.
Bij nader inzien: dit is NIET de code voor de memset: die ziet er zo uit: (inlined dus!)
add r0, sp, #12
str r8, [sp, #12]
movs r5, #46
mov r6, #512
strd r8, r8, [sp, #16]
strd r8, r8, [sp, #24]
strd r8, r8, [sp, #32]
bl lwipInit
Ik heb iets meer code moeten copieren omdat het out-of-order staat. De add r0 is de parameter voor de LWIP_init: sp+12. De struct is kennelijk 28 bytes groot, en wordt met 1 woord en 3 doubleword stores leeg gemaakt, kennelijk is R8 (en R9?) nul en dat weet ie. Wat ie met "r5" en "r6" daar doet weet ik niet/snap ik niet.
Testje: Ik heb boven main een functie toegevoegd:
void set_mac:
void set_mac (lwipthread_opts_t *opts)
{
}
Zo, met warning over ongebruikt argument werkt het wordt er code voor de lwipinit call gemaakt. Haal ik de comment tekens weg: de code stopt kort achter alles wat voor de memset staat.
Pas als ik de set_mac functie in een andere sourcefile zet gaat het goed.....
Het lijkt er op alsof de compiler zich verslikt in het optimaliseren van deze code.
OK.... Te vroeg gejuigd.... met de set_mac functie elders en LTO weer aan.... krijg ik weer 14k aan binary....
Het lijkt er op dat de "opts->macaddress[0] = 0;" hoe je het ook formuleert voor de compliler signaleert: "Dit is het eind van de wereld, de rest hoeft niet meer".
Ik snap er de ballen van.