search

PeterPawn / YourFritz

dynamic package management for AVM routers
GNU General Public License v2.0
225 stars 63 forks source link

avm_kernel_config & GCC v10 optimization #29

Closed fda77 closed 4 years ago

fda77 commented 4 years ago

Bin auf ein neues Betriebssystem gewechselt (x64, selinux, gcc10, ...), seitdem crasht "avm_kernel_config.bin2asm"

$ make kernel-precompiled
Warning: targetAddressSpaceBasePtr(0x80892000) <= targetAddressSpacePtr(0x28758980) violated, doing no conversion
/bin/bash: Zeile 1: 428163 Speicherzugriffsfehler  (Speicherabzug geschrieben) tools/avm_kernel_config.bin2asm "source/kernel/ref-vr9-7490_07.19/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.19-77732-labor.bin" > "source/kernel/ref-vr9-7490_07.19/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.19-77732-labor.S"
make: *** [make/linux/kernel.mk:150: source/kernel/ref-vr9-7490_07.19/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.19-77732-labor.S] Fehler 1
PeterPawn commented 4 years ago

Es gab mal einen Versuch von @RalfFriedl, das auf eine 64-Bit-Version zu ändern ... dazu muß halt die ganze Pointer-Arithmetik angepaßt werden. Ich habe keine Ahnung, was daraus geworden ist ... irgendwann war ich aus der E-Mail-Kommunikation zwischen ihm, @er13 und mir dann raus.

Ich nehme auch mal an, daß Du eher die Version aus dem Freetz-Repo verwendest bzw. daß Dein Fork diese Version aus Freetz nutzt?

https://github.com/Freetz/freetz/tree/master/tools/make/yourfritz-akc-host https://github.com/Freetz-NG/freetz-ng/tree/master/tools/make/yourfritz-akc-host

Die hat @er13 m.W. angepaßt bzw. ggü. der aus meinem Repo stark verändert - bester "Beweis" ist die Tatsache, daß da die Quelltexte direkt im Repo Eurer Forks liegen. Das war auch wieder einer der Streitpunkte zwischen ihm und mir - daher habe ich das praktisch "abgegeben" (https://github.com/Freetz/freetz/commit/c6d056ff64b1fd917f06984c6cd3163591bfe2c5).

Aber ich hoffe Du verstehst, wenn ich da "raus" bin - ich weiß nicht mal genau, wo die Unterschiede zwischen den Versionen liegen und daher wäre das dann eher ein Problem für einen der Freetz-Forks.

Wobei da offensichtlich über HOST_CFLAGS_FORCE_32BIT_CODE beim make ja 32-Bit-Pointer verwendet werden - also hat sich die Frage x86 vs. x64 wohl erledigt.

Wenn Du das verstehst, wäre es nett, wenn Du hier selbst zumachst. Danke.

fda77 commented 4 years ago

Ich kann nichts dafür was er13 mit deinem Code veranstaltet hat. Kannst gern yourfritz-akc-host so umbauen wie yourfritz-host, solang es mindestens noch das macht was vorher machte. Hab übrigens auf die Endianess getippt und nicht Bitness, siehe Überschrift und die Adressen

PeterPawn commented 4 years ago

  1. Du wärst nicht der erste, der "Endianess" mit der "Breite" von Integerzahlen verwechselt, auch wenn ich das mit den Werten der Pointer in der (auch sehr kurz gehaltenen) Fehlermeldung da schon bemerkt habe.

  2. Du erwähnst zwar im ersten Kommentar, daß Du ein anderes OS benutzt, aber da steht nichts von geänderter Hardware und wenn das eine Plattform sein sollte, die sowohl BE als auch LE unterstützt und Du da auch gewechselt hast, fehlt das irgendwie in Deiner Aufzählung.

  3. Du müßtest eigentlich genau wissen, daß man mit den spärlichen Angaben im ersten Beitrag praktisch gar nichts anfangen kann, selbst wenn man das irgendwie nachstellen wollte. Da gehören dann deutlich konkretere Angaben hinein ... angefangen bei der verwendeten Plattform, der Benennung des verwendeten OS und - last but not least - ein Protokoll der Übersetzung der entsprechenden Quellen, damit man wenigstens sehen kann, welche Flags da bei der Übersetzung verwendet wurden - wärst Du mit den bisher "bekannten Fakten" tatsächlich in der Lage, das Problem irgendwie zu reproduzieren, wenn Du das müßtest und außer "selinux" und "x64" und "gcc10" keine weiteren Infos zur verwendeten Umgebung hast?

  4. Auch wenn wir mal unterstellen wollen, daß wir beide üblicherweise "normal" miteinander kommunizieren würden, wäre ein

Kannst gern yourfritz-akc-host so umbauen wie yourfritz-host, solang es mindestens noch das macht was vorher machte.

vielleicht nicht gerade das, was mich dazu motivieren würde, mir das tatsächlich anzusehen. Das geht eigentlich im ersten Kommentar schon los ... was würdest Du mit einer solchen "Fehlermeldung" machen? Was da inhaltlich fehlt, habe ich oben schon geschrieben und hinsichtlich Ausführlichkeit (und ggf. auch hinsichtlich "Ton") hast Du schon noch deutlichen Nachholbedarf.

5., Wenn Du das als Fehlermeldung für Freetz "eingekippt" hast und diese die Voraussetzungen so weit erfüllt, daß man damit etwas anfangen kann, schaue ich vielleicht auch mal drüber, wenn sich @er13 der Sache nicht annimmt. Ich habe - sicherlich verständlicherweise? - keine Lust, das alles doppelt zu machen. Du erinnerst Dich sicherlich, daß ich Dir zuerst das "Prinzip", wie ich es machen würde, ausführlich erklärt hatte (https://www.ip-phone-forum.de/threads/fw-6-50-f%C3%BCr-7490-in-trunk-rev-13490-keine-auswahlm%C3%B6glichkeit.282943/post-2176502 - Deine Beiträge zwischendrin hast Du dann gelöscht) und es erst dann, als Du nichts gemacht hast und auch von @er13 nichts kam, selbst geschrieben hatte. Kaum war es "draußen", wurde es (aus meiner Sicht) vereinnahmt - ich finde gerade Deine Proteste dagegen auch nicht mehr (soviel zu

Ich kann nichts dafür was er13 mit deinem Code veranstaltet hat.

) und wenn ich mich jetzt nicht hinstelle und das in fremdem Code ändere, dann ist das für mich nur konsequent - das habe ich mehr als deutlich angesagt: https://www.ip-phone-forum.de/threads/fehlende-bestandteile-im-opensource-paket-von-avm.287995/post-2259254 und vorhergehende Diskussionen mit @er13 in diesem Thread. Das geht so weit, daß es die Funktion, aus der die im ersten Kommentar gezeigte Warnung ausgegeben wird, bei mir gar nicht gibt - schon deshalb bist Du bei mir da eigentlich falsch, wenn Du jetzt darauf abheben willst, daß ich irgendwann mal die erste Version davon geschrieben hatte.

Wenn Du mich also dazu "motivieren" möchtest, da noch einmal einen Blick hineinzuwerfen, dann gehst Du das irgendwie falsch an. Die "Endianess" des Kernels, aus dem der Dump stammt, wurde bei mir automatisch ermittelt - https://github.com/PeterPawn/YourFritz/blob/master/avm_kernel_config/avm_kernel_config_helpers.c#L76 - und dann bei Bedarf (wenn der Host eine andere Darstellung verwendete) korrigiert vor weiteren Berechnungen mit dem Wert - damit braucht Deine Vermutung, es läge an der "Endianess" automatisch natürlich auch noch einen guten Grund, warum diese Erkennung fehlschlagen sollte.

Sollte der Fehler bei Dir auch mit meinem Code auftreten (wie der anzuwenden wäre, habe ich im IPPF beschrieben, als ich ihn "vorgestellt" habe und das sollte auch heute noch funktionieren) und Du Dich bereit finden, das auch entsprechend zu dokumentieren, dann sind die Chancen deutlich höher, daß ich es mir noch einmal ansehe.

Denn auch wenn ich das "herleiten" kann, daß Du da offensichtlich die 113.07.19-77732 als Vorlage verwenden willst (Würdest Du tatsächlich selbst eine "Fehlermeldung" bearbeiten, wo der Benutzer nicht mal in der Lage war, das Modell und die verwendete FRITZ!OS-Version "sauber" anzugeben?), wäre es ja tatsächlich immer noch denkbar, daß AVM da weitere Daten zu diesem Bereich in den letzten Labor-Versionen hinzugefügt hat und es am Ende überhaupt nichts damit zu tun hat, daß bzw. ob Du nun ein neues System verwendest oder nicht.

AVM braucht da nur minimal das Format zu ändern, damit das nicht länger 1:1 funktioniert. Was bei der 7490 ja problemlos ginge, denn da kommen all diese Daten ja aus dem "avm_kernel_config"-Bereich und wenn der (AVM-)Code zum "Auslesen" an diese Änderungen angepaßt wird, kann man das Format "auf links krempeln", wenn man das will.

Es gäbe also durchaus auch mehrere "Erklärungen" für ein solches Problem ... das sollte Dir aber auch selbst bewußt sein und so hätte ich erwartet (bzw. würde das immer noch erwarten), daß Du da eben nicht nur mit der neuesten Labor-Version testest, sondern zunächst mal mit einer älteren, wo dieser Code definitiv funktioniert ... und es bei Dir vermutlich auf der vorhergehenden Installation (ohne "x64", "selinux" und "gcc10") auch tat.

Wenn das dann funktionieren sollte, müßte man sich den AVM-Inhalt neu ansehen ... durchaus denkbar, daß man dort irgendwelche zusätzlichen Strukturen hinzugefügt hat, die wiederum mit "fester Endianess" arbeiten und wo die Umwandlung zwischen Kernel- und Host-Format nicht immer richtig ist.

Und exakt aus den oben genannten Gründen mache ich hier jetzt auch selbst zu ... Du kannst ja bei Deiner (bitte etwas ausführlicheren) Fehlermeldung im Freetz-Repo (ich kann es auch nicht ändern, daß Du da halt aufschlagen müßtest - angesichts der wechselseitigen Übernahme von Commits zwischen den beiden Forks sollte das ja nicht "vollkommen unmöglich" sein) dann auf diese Diskussion hier verweisen.

fda77 commented 4 years ago

Du kannst dir sicher sein dass ich hier kein Issue erstellen würde wenn ich es selbst auf die schnelle beheben könnte. Mein Ton seh ich als sachlich an, wüsste nicht was es daran auszusetzen gib Bei freetz-er13 werd ich keine Issue öffnen, mein letztes issue dort ist 1 Jahr her, und wurde abgewürgt. Eine "Wechselseitigkeit" gibt es nicht, wenn was von ng übernommen wurde war es meist unter eigenen Namen. Auf er13 brauchst du eh nicht zu hoffen.

Das ist kein spezielles Labor-Problem, mir 7490 stable 7.1x tritt der Fehler auch auf. (gibt übrigens labor-sourcen). Es muss also an der neuen VM auf der gleichen Hardware liegen, vorher fedora30x86 jetzt fedora32x64. Hab da auch Dinge wie dass "sed -i" unter fakroot nicht mehr will

Log 

$$ make  yourfritz-akc-host-dirclean ; make kernel-precompiled
rm -f -r /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host
rm -f -r /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host
mkdir -p /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host
tools/tar-gnu -cf - -C tools/make/yourfritz-akc-host/src --exclude=.svn --exclude=.git --exclude=.gitignore --exclude=.build-prereq-checked --exclude=.unpacked --exclude=.configured --exclude=.compiled --exclude=.installed . | tools/tar-gnu -xf - -C /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host;
touch /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host/.unpacked
make -j9 -C /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host \
        CC="gcc" \
        BITNESS="-m32" \
        LIBFDT_DIR=/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt \
        avm_kernel_config.extract avm_kernel_config.bin2asm
make[1]: Verzeichnis „/home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host“ wird betreten
gcc -O2 -m32 -std=c99 -W -Wall -I/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o avm_kernel_config.extract.o avm_kernel_config.extract.c
gcc -O2 -m32 -std=c99 -W -Wall -I/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o lib_avm_kernel_config.o lib_avm_kernel_config.c
gcc -O2 -m32 -std=c99 -W -Wall -I/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o memory_mapped_file.o memory_mapped_file.c
gcc -O2 -m32 -std=c99 -W -Wall -I/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o avm_kernel_config.bin2asm.o avm_kernel_config.bin2asm.c
gcc -m32  avm_kernel_config.bin2asm.o lib_avm_kernel_config.o memory_mapped_file.o  -L/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -lfdt -o avm_kernel_config.bin2asm
gcc -m32  avm_kernel_config.extract.o lib_avm_kernel_config.o memory_mapped_file.o  -L/home/rolle/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -lfdt -o avm_kernel_config.extract
make[1]: Verzeichnis „/home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host“ wird verlassen
touch -c /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host/avm_kernel_config.extract
mkdir -p tools/; cp /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host/avm_kernel_config.extract tools/avm_kernel_config.extract;
mkdir -p tools/; cp /home/rolle/freetz-ng/source/host-tools/yourfritz-akc-host/avm_kernel_config.bin2asm tools/avm_kernel_config.bin2asm;
/bin/bash: Zeile 1: 17539 Speicherzugriffsfehler  (Speicherabzug geschrieben) tools/avm_kernel_config.bin2asm "source/kernel/ref-grx5-7583_07.10/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7590-07.12.bin" > "source/kernel/ref-grx5-7583_07.10/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7590-07.12.S"
make: *** [make/linux/kernel.mk:150: source/kernel/ref-grx5-7583_07.10/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7590-07.12.S] Fehler 1

Hoffe das sind alle Infos die du brauchst

PeterPawn commented 4 years ago

Hoffe das sind alle Infos die du brauchst

Nein, das sind sie definitiv nicht alle.

Das geht schon damit los, daß Du jetzt plötzlich auf eine 7590 wechseln willst (auch das muß man erst wieder "erraten" anhand von Pfadnamen, weil Du es nicht für notwendig erachtest, wenigstens das aufzuschreiben), die ihrerseits den FDT aus dem Bootloader kriegt und wo daher irgendwelche "Fehler", die AVM dort in den (als "letzte Reserve" m.W. trotzdem noch vorhandenen) FDT für SubRev 0 einbauen würde im "avm_kernel_config"-Bereich, gar keine Auswirkungen mit einem AVM-Kernel hätten, weil sie ohnehin sofort wieder im Setup des Kernels überschrieben würden.

Das ist/wäre bei einer 7490 wieder anders - und mal ehrlich, ich hätte anstelle von AVM auch schon mal "ausgelotet", wie schnell "die Community" auf kleine, fiese, gemeine Änderungen reagieren kann ... schließlich weigert man sich dort "seit Jahren", diesen Teil der Build-Toolchain irgendwie zu veröffentlichen und da würde ich jetzt nicht darauf wetten, daß irgendein "Gewissen" die Handelnden bei AVM davon abhalten könnte.

Andererseits würde ich es sogar verstehen, wenn es da weitere (sinnvolle) Änderungen geben sollte in diesem Bereich - die Umstellung von AVM-Code auf die Benutzung der Crypto-Hardware könnte ja auch einige zusätzliche Einträge in diesem Bereich nach sich ziehen und auch das würde dann wieder die 7590 von einer 7490 unterscheiden - die Zeit, das jetzt erst einmal "zu ermitteln", WILL ich gar nicht investieren.

Außerdem habe ich keine 7590 (max. eine 7580) und daher bleiben wir dann bitte auch bei der 7490, wenn damit das Problem reproduzierbar ist und zwar bei einer 113.07.12-69996 (m.W. die letzte Release-Version der 7490).

Dein Hinweis, daß Labor-Quellen vorliegen, ist ziemlich witzlos oder meinst Du wirklich, ich hätte das in den vergangenen zwei Monaten nicht bemerkt, nachdem ich im IPPF noch geschrieben habe, daß AVM mir dazu geantwortet hat; https://www.ip-phone-forum.de/threads/unter-die-haube-geschaut-%C3%84nderungen-neuigkeiten-im-fritz-os-der-labor-reihe-07-19.305167/post-2360713 - daß Du da nach wie vor "mitliest", merkt man spätestens dann, wenn man von anderen IPPF-Lesern erfährt, daß Du mit ihnen über "Conversations" Kontakt aufgenommen hast.

Aber AVM hat schließlich auch die verwendete C-Library bereits einmal mitten im Labor-Rennen gewechselt (und zwar unmittelbar nachdem die erste Version der 07.19-Quellen für die 7490 draußen waren: https://www.ip-phone-forum.de/threads/unter-die-haube-geschaut-%C3%84nderungen-neuigkeiten-im-fritz-os-der-labor-reihe-07-19.305167/post-2356170) und NIEMAND weiß genau, ob es nicht weitere Änderungen am Kernel gegeben hat ... Du erwartest also hoffentlich nicht, daß man sich jetzt auf die Suche nach Fehlern macht, bei denen die Ursache noch nicht einmal sicher ist.

Denn Du mußt Dir schon auch noch die Frage gefallen lassen, ob Du tatsächlich der Ansicht bist, Du wärst der Erste, der mittlerweile ein 64-Bit-System (natürlich mit den Dateien, die man zum Entwickeln von 32-Bit-Programmen braucht, sonst KANN das Tool, um das es hier geht, gar nicht funktionieren) verwendet? Wenn das bei Dir nach dem Umstieg auf Fedora x64 nicht funktionieren will, kann durchaus auch immer noch Dein eigenes System die Ursache sein und auch dann wäre es ziemlich dämlich, wenn sich ein anderer auf die Suche macht.

Außerdem KANN das auch keine Labor-Version für einen solchen Test sein ... das "originale Freetz" enthält bisher keinerlei Support für die Labor-Reihe 07.19 von AVM und Du erwartest jetzt hoffentlich nicht, daß ich mir für die Fehlersuche Deinen Fork installiere, nur damit ich da irgendetwas mit der Labor-Version nachstellen kann, oder? Ich weiß nicht mal genau, ob Du da inzwischen 07.19-Support "offiziell" drin hast - ich beobachte die Entwicklung dort nämlich nicht permanent, auch das habe ich oft genug deutlich gemacht.

Normalerweise würde ich sogar nach einer passenden Konfigurationsdatei fragen, damit ich mir die richtige Umgebung (und zwar - wenn überhaupt - unter meinem YourFreetz-Fork, denn dafür habe ich die Toolchains, etc. fertig und muß nicht erst bei Null anfangen) nicht erst "zusammensuchen" muß ... allerdings weiß ich natürlich, daß das bei Dir nicht so ohne weiteres geht, weil die Konfigurationen ja nicht mehr austauschbar sind.

Aber ich finde es ehrlich gesagt überhaupt nicht unbillig, von Dir bei einer Fehlermeldung zu erwarten, daß Du diese dann so abgibst (und zwar eigentlich auch wieder im Freetz-Repo und mir ist es vollkommen egal, was @er13 dazu sagt, denn die Blöße, da "Diskussionen zu verbieten", gibt er sich sicherlich auch nicht), daß man sie mit dem Inhalt des Freetz-Repos ohne weiteres nachstellen kann - ja, ich würde sogar erwarten, daß Du mit einem anderen 64-Bit-OS (meinetwegen Ubuntu 18.04 LTS: https://releases.ubuntu.com/18.04.4/) zuerst noch einmal prüfst, ob es nicht am Ende doch nur Deine Fedora-Installation ist, die sich als Ursache des Problems herausstellt (dann könnte man da zwar immer noch suchen, aber auch da wird sich wohl niemand erst mal eine passende VM mit Fedora bauen, nur um Deinem Problem auf den Grund zu gehen).

So eine "Gegenprobe" mit einem anderen System wäre aber allemal fairer, als jemand anderen in die Spur zu schicken und ggf. am Ende dann - schulterzuckend - festzustellen, daß es doch an Deinem Build-Host lag - und die zweite Probe wäre es dann, ob das auch mit dem Freetz-Repo reproduzierbar ist, wobei dann gleich noch die passende ".config" (bzw. ".config.compressed") abfällt für die "formgerechte Fehlermeldung".

Wenn Du das alles schon gemacht hast bzw. was Du bisher tatsächlich alles schon probiert und als Ursache ausgeschlossen hast, hast Du offenbar vergessen genauer zu "erklären".

Immerhin weiß ich dank

Du kannst dir sicher sein dass ich hier kein Issue erstellen würde wenn ich es selbst auf die schnelle beheben könnte.

ja nunmehr, daß es nicht Deine "erste Wahl" war, hier eine Issue zu eröffnen, aber das, was Du bisher schon "ausgeschlossen" hast für Dich, ist ja offenbar weiterhin "geheim" und dann mußt Du Dich auch nicht wundern, wenn man Dir erst einmal Fragen stellt oder Alternativen vorschlägt, die Du natürlich alle schon lääängst für Dich geprüft hast.

Und damit sind wir dann auch bei dem, was ich meinerseits als "Ton" bemängele ... da geht es mir nicht um fehlende Sachlichkeit - aber ein "Telegrammstil", der obendrein noch die grundlegendsten Informationen ausläßt und dem Gegenüber nicht einmal "ausformulierte Sätze" gönnt (denn so etwas:

Bin auf ein neues Betriebssystem gewechselt (x64, selinux, gcc10, ...), seitdem crasht "avm_kernel_config.bin2asm"

kann man wohl kaum als "Fehlermeldung" ansehen), der gehört nicht zu meinem Kommunikationsgebahren und wenn man selbst etwas vom Gegenüber will, sollte man zumindest die "Höflichkeit" aufbringen, sich diesem Gegenüber auch wenigsten minimal anzupassen.

Da gehört in einen Satz ein Subjekt (oben wäre das ein "ich"), ein Prädikat und ein Objekt - und da das hier kein Twitter mit beschränkter Nachrichtenlänge ist, kann man das auch problemlos "richtig" machen. Und wenn Du Deine "Ansage":

Kannst gern yourfritz-akc-host so umbauen wie yourfritz-host, solang es mindestens noch das macht was vorher machte.

tatsächlich für "sachlich" hältst und nicht als "unhöflich" siehst (es ist ja nett, daß Du mir den Umbau zugestehst, auch wenn Du gleich wieder eine Forderung dranhängst, wie ich das dann zu machen hätte - mal abgesehen vom erneut fehlenden Subjekt im Satz), dann haben wir halt unterschiedliche Vorstellungen.

Nur wirst Du hier halt nicht umhin kommen, Dich MEINEN Vorstellungen anzupassen, ansonsten erlebst Du (wenn auch aus anderen Gründen) mit mir dasselbe, was Du mit @er13 bereits erlebt hast.

Ich brauche niemanden, der sich wie eine offene Hose benimmt - Sachlichkeit und Höflichkeit (dazu gehört für mich eine Sprache, bei der ich nicht "raten" muß, was mir Sätze sagen wollen - so viel Zeit muß dann schon sein und zwar nicht nur beim Lesen meiner Antworten, sondern auch beim eigenen Schreiben) schließen sich nicht zwangsläufig aus.

fda77 commented 4 years ago

Bin mir nicht so sicher wie das alles bei dem Problem weiterhilft. Hatte aus versehen die 7590 ausgewählt, aber es ging ja um das Log des bauen vom Tool. Ubuntu LTS macht keinen Sinn, da kann ich auch beim alten Fedora bleiben. Fehler die heut mit Fedora auftauchen sehen LTS user erst in Jahren. Ein mit x86 gebautes labor-image für die 7490 läuft mit replace kernel. Der Fehler muss also an deinem Tool liegen (Endianess). Bin sicher dass es sich genau so mit freetz-er13 verhält, da es da keine Unterschiede gibt

PeterPawn commented 4 years ago

Ich vermute auch mal, Du willst es gar nicht wirklich verstehen?

aber es ging ja um das Log des bauen vom Tool.

Nein, es ging nicht nur darum. Da steht deutlich:

Da gehören dann deutlich konkretere Angaben hinein ... angefangen bei der verwendeten Plattform, der Benennung des verwendeten OS und - last but not least - ein Protokoll der Übersetzung der entsprechenden Quellen, damit man wenigstens sehen kann, welche Flags da bei der Übersetzung verwendet wurden

und das "last but not least" besagt ja wohl deutlich, daß das Protokoll der Übersetzung nur ein einzelnes "Puzzle-Teil" wäre oder verstehst Du das anders? Hätte ich jetzt tatsächlich JEDE EINZELHEIT aufzählen müssen, die man von Dir erfahren muß, um das auch nur im Ansatz nachstellen zu können? Oder kann man ein "angefangen bei" auch nur als "Einstieg" verstehen und nicht so, daß da eine komplette Aufzählung folgen müsse?

Was Du dann hast "gucken lassen", sind exakt die drei Punkte, die ich als Beispiele angeführt habe - würdest Du so etwas tatsächlich "bearbeiten", wenn das einer Deiner Nutzer Dir als "Fehlermeldung" zumuten würde?

Soll ich tatsächlich "raten", was Du als Umgebung für den Build und als Konfiguration verwendest?

Ich weiß - auch nur ein weiteres Beispiel, ohne Anspruch auf Vollständigkeit - nicht einmal (und ich will da jetzt auch nicht nachsehen, ob es das überhaupt noch gibt in Freetz-NG), was Du für FREETZ_TOOLCHAIN_32BIT als Einstellung verwendest, ich habe keinen Schimmer, welche anderen Komponenten wie Compiler-Version, C-Libraries oder binutils Du bei Dir benutzt ... aber ich soll irgendwie versuchen, Dein Problem nachzustellen?

Hast Du vielleicht schon selbst einmal geprüft, was man bei einer Google-Suche nach "fedora32x64" (exakt so steht es bei Dir im fünften Kommentar oben) als Hinweis darauf findet, was Du da überhaupt in der VM installiert haben könntest?

Weißt Du, was ein Subjekt (und hier meine ich deutsche Grammatik) in einem Satz ist? Wenn nicht, empfehle ich Dir folgenden Link.

Und der sicherste Weg für Dich, wenn Du möchtest, daß ich die Kommunikation hier komplett abbreche, wäre es, weiterhin von "Deinem Programm" (oder "Deinem Tool") zu sprechen bzw. zu schreiben.

Wenn Du DAS bisher noch nicht verstanden hast, daß Dein Problem bisher mit MEINEM Tool noch gar nicht "bestätigt" wurde (die Aufforderung meinerseits, das doch einfach mal mit meiner Version auch tatsächlich als Gegenprobe zu testen (hier im zweiten Absatz unter dem ersten Ruler zu finden; https://github.com/PeterPawn/YourFritz/issues/29#issuecomment-624206245), hast Du ja offenbar ignoriert) und es bei Dir mit dem Tool von @er13 auftritt, dann macht das auch wenig Sinn, da irgendwie weiter "zu reden".

Ich verstehe auch nicht im geringsten, warum Du ständig auf der Endianess herumreitest ... wenn Du Dein System von einem 32-bittigen Fedora auf ein 64-bittiges aktualisiert hast, warum sollte sich dabei die Endianess des Build-Hosts irgendwie ändern? Das ist bei einem 32-Bit-OS auf x86 ebenso LE, wie bei einem 64-Bit-OS auf x64 und die 7490 verwendet immer BE.

Da hat sich "an der Gesamtsituation" also dadurch, daß Du jetzt ein anderes OS für Deinen Build verwendest, überhaupt nichts verändert.

Worauf willst Du damit also genau hinaus? Es ist ja nicht so, daß Du nur in unvollständigen Sätzen schreiben würdest ... Du schreibst auch noch (für mich zumindest) in Rätseln und jede Nachfrage nach einer plausiblen Theorie oder Begründung für eine Annahme verhallt ungehört.

Ich habe meinerseits nämlich gar kein Problem, auf einem (durchaus auch aktuellen) x64-System:

peh@vidar:~/freetz> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20200413"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20200413"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20200413"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
LOGO="distributor-logo"
peh@vidar:~/freetz> uname -a
Linux vidar 5.6.2-1-default #1 SMP Thu Apr 2 06:31:32 UTC 2020 (c8170d6) x86_64 x86_64 x86_64 GNU/Linux
peh@vidar:~/freetz> gcc --version
gcc (SUSE Linux) 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
peh@vidar:~/freetz>

die Version aus dem Freetz-Repo zu übersetzen:

[...]
rm -f -r /home/peh/freetz/source/host-tools/yourfritz-akc-host
mkdir -p /home/peh/freetz/source/host-tools/yourfritz-akc-host
tools/tar-gnu -cf - -C tools/make/yourfritz-akc-host/src --exclude=.svn --exclude=.git --exclude=.gitignore --exclude=.build-prereq-checked --exclude=.unpacked --exclude=.configured --exclude=.compiled --exclude=.installed . | tools/tar-
gnu -xf - -C /home/peh/freetz/source/host-tools/yourfritz-akc-host;
touch /home/peh/freetz/source/host-tools/yourfritz-akc-host/.unpacked
make -j2 -C /home/peh/freetz/source/host-tools/yourfritz-akc-host \
        CC="gcc" \
        BITNESS="-m32" \
        LIBFDT_DIR=/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt \
        avm_kernel_config.extract avm_kernel_config.bin2asm
make[1]: Entering directory '/home/peh/freetz/source/host-tools/yourfritz-akc-host'
gcc -O2 -m32 -std=c99 -W -Wall -I/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o avm_kernel_config.extract.o avm_kernel_config.extract.c
gcc -O2 -m32 -std=c99 -W -Wall -I/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o lib_avm_kernel_config.o lib_avm_kernel_config.c
gcc -O2 -m32 -std=c99 -W -Wall -I/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o memory_mapped_file.o memory_mapped_file.c
gcc -O2 -m32 -std=c99 -W -Wall -I/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o avm_kernel_config.bin2asm.o avm_kernel_config.bin2asm.c
gcc -m32  avm_kernel_config.extract.o lib_avm_kernel_config.o memory_mapped_file.o  -L/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt -lfdt -o avm_kernel_config.extract
gcc -m32  avm_kernel_config.bin2asm.o lib_avm_kernel_config.o memory_mapped_file.o  -L/home/peh/freetz/source/host-tools/dtc-1.4.5/libfdt -lfdt -o avm_kernel_config.bin2asm
make[1]: Leaving directory '/home/peh/freetz/source/host-tools/yourfritz-akc-host'
touch -c /home/peh/freetz/source/host-tools/yourfritz-akc-host/avm_kernel_config.extract
mkdir -p tools/; cp /home/peh/freetz/source/host-tools/yourfritz-akc-host/avm_kernel_config.extract tools/avm_kernel_config.extract;
mkdir -p tools/; cp /home/peh/freetz/source/host-tools/yourfritz-akc-host/avm_kernel_config.bin2asm tools/avm_kernel_config.bin2asm;
[...]

und mit ihr aus dem Kernel auch die Daten zu extrahieren:

[...]
tools/avm_kernel_config.extract.sh -s 64 "dl/fw/FRITZ.Box_7490.113.07.12.image" >"source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.bin" || { rm -f "source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.bin"; exit 1; }
tools/avm_kernel_config.bin2asm "source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.bin" >"source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.S" || { rm -f "source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.S"; exit 1; }
[...]

Wobei die Zeilen oben nur zu sehen sind, wenn man das Makefile für den Kernel anpaßt, weil die normalerweise mit einem @ in der ersten Position "ruhiggestellt" sind:

peh@vidar:~/freetz> git diff | cat
diff --git a/make/linux/kernel.mk b/make/linux/kernel.mk
index 416ae60d4..7351024ef 100644
--- a/make/linux/kernel.mk
+++ b/make/linux/kernel.mk
@@ -144,10 +144,10 @@ $(AVM_KERNEL_CONFIG_DIR): | $(KERNEL_DIR)/.unpacked
        @mkdir -p $@

 $(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).bin: $(DL_FW_DIR)/$(DL_SOURCE_LOCAL) | $(KERNEL_DIR)/.unpacked $(AVM_KERNEL_CONFIG_DIR) tools
-       @$(TOOLS_DIR)/avm_kernel_config.extract.sh -s $(FREETZ_AVM_KERNEL_CONFIG_AREA_SIZE) "$<" >"$@" || { $(RM) "$@"; exit 1; }
+       $(TOOLS_DIR)/avm_kernel_config.extract.sh -s $(FREETZ_AVM_KERNEL_CONFIG_AREA_SIZE) "$<" >"$@" || { $(RM) "$@"; exit 1; }

 $(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).S: $(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).bin | $(KERNEL_DIR)/.unpacked $(AVM_KERNEL_CONFIG_DIR) tools
-       @$(TOOLS_DIR)/avm_kernel_config.bin2asm "$<" >"$@" || { $(RM) "$@"; exit 1; }
+       $(TOOLS_DIR)/avm_kernel_config.bin2asm "$<" >"$@" || { $(RM) "$@"; exit 1; }

 # Force kernel rebuild if avm_kernel_config_area.S differs from avm_kernel_config_area.$(DL_SOURCE_ID).S
 # To reduce maintenance effort we often use the same opensrc package for different boxes.
peh@vidar:~/freetz>

Aber danach existiert dann die Assembler-Datei auch am richtigen Ort:

peh@vidar:~/freetz> ls -l source/kernel/ref-vr9-7490_07.11/linux/arch/mips/kernel/avm_kernel*
-rw-r--r-- 1 peh users 65536 May  6 18:30 source/kernel/ref-vr9-7490_07.11/linux/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.bin
-rw-r--r-- 1 peh users 32332 May  6 18:30 source/kernel/ref-vr9-7490_07.11/linux/arch/mips/kernel/avm_kernel_config_area.7490.113.07.12.S
-rw-r--r-- 1 peh users  8912 May  6 18:31 source/kernel/ref-vr9-7490_07.11/linux/arch/mips/kernel/avm_kernel_config_area.o
-rw-r--r-- 1 peh users 32332 May  6 18:30 source/kernel/ref-vr9-7490_07.11/linux/arch/mips/kernel/avm_kernel_config_area.S
-rw-r--r-- 1 peh users  1674 May  6 17:05 source/kernel/ref-vr9-7490_07.11/linux/arch/mips/kernel/avm_kernel_config_macros.h
peh@vidar:~/freetz>

Wenn Du also darauf bestehst, daß es da gar keinen Unterschied zwischen Freetz-NG und Freetz gibt, müßte mein Tumbleweed ja genau dasselbe Ergebnis erzielen, wenn es Freetz-NG versucht zu übersetzen.

Das heißt dann am Ende aber auch, daß das Problem wohl doch eher in Deinem Build-Host zu suchen ist, als im Quelltext der Programme, die für das Auslesen der "avm_kernel_config"-Bereiche verwendet werden können - wobei ich hier jetzt tatsächlich MEINE Version auch gar nicht getestet habe, sondern exakt die, welche sich im Freetz-Repo findet (das ist also nicht mal mein YourFreetz-Fork, für den ich mir hier mal die Mühe gemacht habe, den auf diesem (Arbeits-)System zu übersetzen).

Vielleicht überlegst Du Dir ja doch noch einmal, was Deinen Build-Host nun von anderen x64-Systemen unterscheiden könnte ... der verwendete GCC auf dem Host, mit dem dann erst mal der GCC für die weitere Verwendung mit Freetz erstellt wird, sollte ja am Ende eigentlich keine Auswirkungen darauf haben, wie der GCC 5.5.0 (der hier von mir verwendet wurde) funktioniert.

Und damit dann auch keine Unklarheiten hinsichtlich der von mir verwendeten Freetz-Konfiguration bestehen ... hier ist die von mir verwendete Konfiguration (allerdings nur die "compressed"-Version):

peh@vidar:~/freetz> make config-compress
Compressed configuration written to .config.compressed.
It is equivalent to .config, but contains only non-default user selections and no signing key password.
peh@vidar:~/freetz> cat .config.compressed
FREETZ_USER_LEVEL_EXPERT=y
FREETZ_TYPE_FIRMWARE_07_1X=y
FREETZ_REPLACE_KERNEL=y
peh@vidar:~/freetz>

... es sind also eigentlich alles "Standardeinstellungen", weil die 7490 ja voreingestellt ist und ich nur auf die 07.12 umstellen mußte.

Vielleicht kannst Du mir ja doch noch eine valide Theorie anbieten, warum das an dem Tool liegen soll? Und hier ist es mir auch egal, ob wir über meine erste Version reden oder über die umgearbeitete von @er13 ... logisch ist es erst einmal nicht, hier einen Fehler in den Quellen zu vermuten.

Eher schon würde es mir einleuchten, wenn Dein Build-Host irgendwelche komischen Makros in seinen Kernel-Sourcen verwendet, die dann am Ende auch bis zum GCC 5.5.0 für Freetz durchschlagen (der Compiler für den Build-Host nutzt ja die Header-Files des Hosts) und letztlich dazu führen, daß mit "-m32" übersetzte Programme nicht das machen, was sie eigentlich sollen. Nur wäre das dann ein Problem für die Macher von Fedora und hätte mit dem von Dir angesprochenen Tool nur insoweit zu tun, als es dort auffällt.

Wobei ich hier sogar davon ausgehe, daß Du auch alles richtig für Deine Distribution installiert hast ... bis hin zur Unterstützung für die Entwicklung und die Benutzung von 32-Bit-Programmen auf einem 64-Bit-System. Wenn Du da irgendwo einen Fehler gemacht hast und dem hier von Dir angesprochenen Problem schon andere vorausgingen, die Du dann "irgendwie" gelöst hast, wäre das eine weitere denkbare Fehlerquelle.

In Anbetracht all dessen, was ich jetzt versucht habe zu vermitteln, kann ich tatsächlich nicht erkennen, warum das ein Problem für mich oder auch für @er13 bzw. für den Code in "yourfritz-akc-host" sein sollte. Solange Du das nicht plausibel machen kannst, werde ich daher auch nichts weiter suchen.

Wie ich schon weiter oben schrieb ... ich habe keinen Bock, daß nach entsprechenden Aufständen, die man/ich jetzt bei der Fehlersuche macht bzw. machen müßte (schon die Benutzung eines Freetz-Forks und das Erstellen eines Images damit, war für mich reiner Zusatzaufwand, weil ich damit ansonsten gar nichts anfangen kann bzw. will), am Ende nur ein Schulterzucken und ein "Dann liegt es wohl an meinem Build-Host." dabei herauskommt und das läuft hier für mich exakt in diese Richtung. Siehst Du das anders, überzeuge mich ... aber nicht nur mit Worten, sondern mit Dateien und Protokollen (und zwar kompletten).

fda77 commented 4 years ago

Funfact vorweg: Die Binary die mit dem x86 erstellt wurde funktioniert auf dem x64 System... komisch

$$ tools/avm_kernel_config.bin2asm "source/kernel/ref-grx5-7583_07.10/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7590-07.12.bin"
Speicherzugriffsfehler (Speicherabzug geschrieben)

$$ tools/avm_kernel_config.bin2asm "source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.12.bin"

vomX86kopiert/avm_kernel_config.bin2asm "source/kernel/ref-grx5-7583_07.10/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7590-07.12.bin" | head
#include "avm_kernel_config_macros.h"

        AVM_KERNEL_CONFIG_START

        AVM_KERNEL_CONFIG_PTR

.L_avm_kernel_config_entries:
        AVM_KERNEL_CONFIG_ENTRY 1, "module_memory"
        AVM_KERNEL_CONFIG_ENTRY 2, "version_info"
        AVM_KERNEL_CONFIG_ENTRY 5, "device_tree_subrev_0"

$$ vomX86kopiert/avm_kernel_config.bin2asm "source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.12.bin" |head
#include "avm_kernel_config_macros.h"

        AVM_KERNEL_CONFIG_START

        AVM_KERNEL_CONFIG_PTR

.L_avm_kernel_config_entries:
        AVM_KERNEL_CONFIG_ENTRY 1, "module_memory"
        AVM_KERNEL_CONFIG_ENTRY 2, "version_info"
        AVM_KERNEL_CONFIG_ENTRY 5, "device_tree_subrev_0"

$$ file  vomX86kopiert/avm_kernel_config.bin2asm tools/avm_kernel_config.bin2asm
vomX86kopiert/avm_kernel_config.bin2asm: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=8e2f3587f0ca68d6f54de8fbd6ff72f50f3398d0, not stripped
tools/avm_kernel_config.bin2asm:         ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=2aabb7dd7535b9f4bdad70a2e204d4b62213f988, for GNU/Linux 3.2.0, not stripped

$$ l avm_kernel_config/avm_kernel_config.bin2asm tools/avm_kernel_config.bin2asm
30116 bytes   avm_kernel_config/avm_kernel_config.bin2asm
27720 bytes   tools/avm_kernel_config.bin2asm

Endianess, da vermutlich 1 der beiden Adress umgekehrt da steht. Und nicht vom Sysrem sondern die Erkennung im Tool! Wenn du es besser weisst, raus damit. Das BITNESS in den .mk ist grundsätzlich immer -m32, egal wie man die Toolchain baut (ich hatte x32 in Freetz nicht aktiviert, ccache macht dann Probleme..). Setzt man fest ein -m64 in der mk für dtc-host und yourfritz-akc-host funktioniert es zwar immer noch nicht (wenn auch besser), bringt aber ein paar unsichere Casts

make kernel-precompiled
rm -f -r /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host
mkdir -p /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host
tools/tar-gnu -cf - -C tools/make/yourfritz-akc-host/src --exclude=.svn --exclude=.git --exclude=.gitignore --exclude=.build-prereq-checked --exclude=.unpacked --exclude=.configured --exclude=.compiled --exclude=.installed . | tools/tar-gnu -xf - -C /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host;
touch /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host/.unpacked
make -j9 -C /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host \
        CC="gcc" \
        BITNESS="-m64" \
        LIBFDT_DIR=/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt \
        avm_kernel_config.extract avm_kernel_config.bin2asm
make[1]: Verzeichnis „/home/654645/freetz-ng/source/host-tools/yourfritz-akc-host“ wird betreten
gcc -O2 -m64 -std=c99 -W -Wall -I/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o avm_kernel_config.extract.o avm_kernel_config.extract.c
gcc -O2 -m64 -std=c99 -W -Wall -I/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o lib_avm_kernel_config.o lib_avm_kernel_config.c
gcc -O2 -m64 -std=c99 -W -Wall -I/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o memory_mapped_file.o memory_mapped_file.c
gcc -O2 -m64 -std=c99 -W -Wall -I/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -DUSE_STRIPPED_AVM_KERNEL_CONFIG_H  -c -o avm_kernel_config.bin2asm.o avm_kernel_config.bin2asm.c
lib_avm_kernel_config.c: In Funktion »isConsistentConfigArea«:
lib_avm_kernel_config.c:171:14: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite [-Wpointer-to-int-cast]
  171 |   ptrValue = (uint32_t) entry->config;
      |              ^
lib_avm_kernel_config.c: In Funktion »relocateConfigArea«:
lib_avm_kernel_config.c:240:46: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite [-Wpointer-to-int-cast]
  240 |   entry->config = (void *) targetPtr2HostPtr((uint32_t)entry->config, kernelSegmentStart, configArea);
      |                                              ^
lib_avm_kernel_config.c:252:48: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite [-Wpointer-to-int-cast]
  252 |      module->name = (char *) targetPtr2HostPtr((uint32_t)module->name, kernelSegmentStart, configArea);
      |                                                ^
lib_avm_kernel_config.c:263:48: Warnung: Typkonvertierung von Zeiger auf Ganzzahl anderer Breite [-Wpointer-to-int-cast]
  263 |      module->name = (char *) targetPtr2HostPtr((uint32_t)module->name, kernelSegmentStart, configArea);
      |                                                ^
lib_avm_kernel_config.c: In Funktion »targetPtr2HostPtr«:
lib_avm_kernel_config.c:294:10: Warnung: Typkonvertierung in Zeiger von Ganzzahl anderer Breite [-Wint-to-pointer-cast]
  294 |   return (void*)targetAddressSpacePtr;
      |          ^
gcc -m64  avm_kernel_config.extract.o lib_avm_kernel_config.o memory_mapped_file.o  -L/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -lfdt -o avm_kernel_config.extract
gcc -m64  avm_kernel_config.bin2asm.o lib_avm_kernel_config.o memory_mapped_file.o  -L/home/654645/freetz-ng/source/host-tools/dtc-1.4.5/libfdt -lfdt -o avm_kernel_config.bin2asm
make[1]: Verzeichnis „/home/654645/freetz-ng/source/host-tools/yourfritz-akc-host“ wird verlassen
touch -c /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host/avm_kernel_config.extract
mkdir -p tools/; cp /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host/avm_kernel_config.extract tools/avm_kernel_config.extract;
mkdir -p tools/; cp /home/654645/freetz-ng/source/host-tools/yourfritz-akc-host/avm_kernel_config.bin2asm tools/avm_kernel_config.bin2asm;
Unexpected config area content found, extraction aborted.
make: *** [make/linux/kernel.mk:147: source/kernel/ref-vr9-7490_07.11/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.12.bin] Fehler 1

Wenn du irgend welche Infos braucht frag halt. Wie aktuell Suse ist weiss ich nicht, ist schon lange her dass ich das verwendete. Zu Fedora: Ist dafür bekannt bleeding edge zu sein. Ein Vergleich mit Ubuntu LTS (dazu von 2018) hinkt, die liegen Jahre auseinander. Ich hab nicht geupdated sondern komplett neuinstalliert, Fedora 30 war die letzt x86, jetzt nur noch x64 (Ursache der ganzen Übung)

Ein ganz normales aktuelles neuinstalliertes Fedora:

$$ hostnamectl
         Icon name: computer-vm
           Chassis: vm
  Operating System: Fedora 32 (Thirty Two)
       CPE OS Name: cpe:/o:fedoraproject:fedora:32
            Kernel: Linux 5.6.8-300.fc32.x86_64
      Architecture: x86-64

$$ uname -a
Linux dingens 5.6.8-300.fc32.x86_64 #1 SMP Wed Apr 29 19:01:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$$ gcc --version
gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.13)
Copyright (C) 2020 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

$$ cat /etc/os-release
NAME=Fedora
VERSION="32 (Thirty Two)"
ID=fedora
VERSION_ID=32
VERSION_CODENAME=""
PLATFORM_ID="platform:f32"
PRETTY_NAME="Fedora 32 (Thirty Two)"
ANSI_COLOR="0;34"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:32"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=32
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=32
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"

Die Dinge die du geschrieben hast probier ich nachher aus

fda77 commented 4 years ago

Kurzes Zwischenupdate: Wollte kurz während dem Essen freetz-er bauen. So ein Haufen Mist! Ist natürlich gleich nach Beginn abgebrochen, da die squashfs* host tools so nicht mit gcc10 compilierbar sind. Also den Fix aus NG gebackportet und nochmal von vorne ^^

fda77 commented 4 years ago

So, der Build von freetz-er hat funktioniert. avm_kernel_config.bin2asm verhält sich wie erwartet bei freetz-ng, Fehlermeldung siehe oben. Dann hatte ich noch ein Xubuntu x64 hier, das ich nun auf 20.04 aktualisiert hab. Damit funktioniert avm_kernel_config.bin2asm aus freetz-ng als auch freetz-er wie erwartet fehlerfrei Wie auch schon vermutet ist dir Ursache damit das aktuelle Fedora x64 mit seinen neuesten Paketen (gcc 10.1.1, libtool 2.4.6, glibc 2.31, ka was du noch wissen willst) Wie "Build 32-bit toolchains" konfiguriert ist? Wie der Standard, deaktiviert. Welche Rolle das für avm_kernel_config spielt? Keine, wie man Namen schon erraten könnte hat das Auswirkungen auf die Toolchain, nicht die host-tools. Mindestens yourfritz-akc-host und dtc-host werden immer x86 gebaut.

Dann hab ich erfolglos versucht das avm_kernel_config einfach direkt aus YourFritz zu bauen. Bin vorgegangen wie es in https://github.com/PeterPawn/YourFritz/blob/master/avm_kernel_config/README.md steht:

If you want to compile the contained sources for a specific model, you have to provide a symlink named "linux" to the root of the correct kernel sources.
cd ~/
rm -rf YourFritz
git clone https://github.com/PeterPawn/YourFritz.git
cd YourFritz/avm_kernel_config
tar xf ~/.freetz-dl/fw/7490_07.11-release_kernel.tar.xz
ln -s linux-3.10 linux
patch -p0 < patches/901*
patch -p0 < patches/902*

make

Geht aber nicht:

gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt.c -o linux/scripts/dtc/libfdt/fdt.o
gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt_ro.c -o linux/scripts/dtc/libfdt/fdt_ro.o
gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt_wip.c -o linux/scripts/dtc/libfdt/fdt_wip.o
gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt_sw.c -o linux/scripts/dtc/libfdt/fdt_sw.o
gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt_rw.c -o linux/scripts/dtc/libfdt/fdt_rw.o
gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt_strerror.c -o linux/scripts/dtc/libfdt/fdt_strerror.o
gcc -static -std=c99 -m32 -ggdb -I./linux/scripts/dtc/libfdt -I. -c linux/scripts/dtc/libfdt/fdt_empty_tree.c -o linux/scripts/dtc/libfdt/fdt_empty_tree.o
rm linux/scripts/dtc/libfdt/libfdt.a 2>/dev/null || true
ar rcu linux/scripts/dtc/libfdt/libfdt.a linux/scripts/dtc/libfdt/fdt.o linux/scripts/dtc/libfdt/fdt_ro.o linux/scripts/dtc/libfdt/fdt_wip.o linux/scripts/dtc/libfdt/fdt_sw.o linux/scripts/dtc/libfdt/fdt_rw.o linux/scripts/dtc/libfdt/fdt_strerror.o linux/scripts/dtc/libfdt/fdt_empty_tree.o
ranlib linux/scripts/dtc/libfdt/libfdt.a
gcc -static -std=c99 -m32 -ggdb -O2 -W -Wall -I./linux/scripts/dtc/libfdt -I. -c avm_kernel_config_helpers.c -o avm_kernel_config_helpers.o
In Datei, eingebunden von avm_kernel_config_helpers.c:23:
avm_kernel_config_helpers.h:20:10: schwerwiegender Fehler: linux/include/uapi/linux/avm_kernel_config.h: Datei oder Verzeichnis nicht gefunden
   20 | #include "linux/include/uapi/linux/avm_kernel_config.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kompilierung beendet.
make: *** [Makefile:53: avm_kernel_config_helpers.o] Fehler 1

Die erwarteten Dateien gibt es bei avm wohl nicht:

The files "include/uapi/linux/avm_kernel_config.h" and the whole directory "scripts/dtc/libfdt" (from the OpenFirmware device-tree compiler) are the parts needed from current kernel sources.
find . -name avm_kernel_config.h
./linux/include/linux/avm_kernel_config.h

Wie bekommt man das compiliert? Fehlt da was in der README?

PeterPawn commented 4 years ago

Fehlt da was in der README?

Nicht wirklich.

Erster Schritt:

Diesen Beitrag im IPPF lesen: https://www.ip-phone-forum.de/threads/fehlende-bestandteile-im-opensource-paket-von-avm.287995/post-2184482 ... da waren auch mal Beiträge von Dir enthalten im Thread, es kann Dir also nicht wirklich entgangen sein, daß ich das mit 113.06.60 (bzw. den Quellen dafür) getestet habe, wie ich dort schon im ersten Beitrag deutlich schreibe.

Und die README.md hier enthält auch nicht umsonst die Info, welche Dateien aus dem Source-Tree benötigt werden ... sollten die mal (warum auch immer) ihre Position wechseln, kann/muß man die #include-Statements eben anpassen. Da ist dieses Programm weder das erste, noch das letzte, was davon jemals betroffen war bzw. sein wird.

Nimmt AVM da weitergehende Änderungen vor, müßte man das (wenn man es unter solchermaßen geänderten Bedingungen auch weiterhin benutzen will) an diese Änderungen bei AVM eben anpassen.

Also schauen wir doch mal bei der 06.60 nach, was es da so gab:

vidar:~/osp.avm.de/fritzbox/fritzbox-7490 $ tar -x -f source-files-FRITZ.Box_7490-06.60.tar.gz -z -O GPL/GPL-release_kernel.tar.gz | tar -x -v -z -O --wildcards "*/avm_kernel_config.h"
=== linux-3.10/include/linux/avm_kernel_config.h ===
#ifndef _INCLUDE_LINUX_AVM_KERNEL_CONFIG_H_
#define _INCLUDE_LINUX_AVM_KERNEL_CONFIG_H_

#include <linux/err.h>
#include <uapi/linux/avm_kernel_config.h>

#define AVM_REBOOT_STRING_LOCATION  (0xa1000000 - AVM_REBOOT_STRING_SIZE)
#define AVM_REBOOT_STRING_SIZE      512

extern struct _avm_kernel_config **avm_kernel_config;
extern struct _kernel_modulmemory_config *kernel_modulmemory_config;
extern unsigned char *avm_kernel_config_device_tree[avm_subrev_max];
extern struct _avm_kernel_version_info *avm_kernel_version_info;

static inline int init_avm_kernel_config_ptr(void)
{
        extern unsigned int __avm_kernel_config_start __attribute__ ((weak));

        if (IS_ERR(&__avm_kernel_config_start) ||
            (&__avm_kernel_config_start == NULL))
                return -1;

        avm_kernel_config =
            (struct _avm_kernel_config **)&__avm_kernel_config_start;

        return 0;
}

extern void init_avm_kernel_config(void);

#endif
/* vim: set noexpandtab sw=8 ts=8 sts=0: */
=== linux-3.10/include/uapi/linux/avm_kernel_config.h ===
#ifndef _UAPI_LINUX_AVM_KERNEL_CONFIG_H_
#define _UAPI_LINUX_AVM_KERNEL_CONFIG_H_

enum _avm_kernel_config_tags {
        avm_kernel_config_tags_undef,
        avm_kernel_config_tags_modulememory,
        avm_kernel_config_tags_version_info,
        avm_kernel_config_tags_hw_config,
        avm_kernel_config_tags_cache_config,
        avm_kernel_config_tags_device_tree_subrev_0,  /* subrev müssen aufeinander folgen */
        avm_kernel_config_tags_device_tree_subrev_1,
        avm_kernel_config_tags_device_tree_subrev_2,
        avm_kernel_config_tags_device_tree_subrev_3,
        avm_kernel_config_tags_device_tree_subrev_4,
        avm_kernel_config_tags_device_tree_subrev_5,
        avm_kernel_config_tags_device_tree_subrev_6,
        avm_kernel_config_tags_device_tree_subrev_7,
        avm_kernel_config_tags_device_tree_subrev_8,
        avm_kernel_config_tags_device_tree_subrev_9,  /* subrev müssen aufeinander folgen */
        avm_kernel_config_tags_device_tree_subrev_last = avm_kernel_config_tags_device_tree_subrev_9,
        avm_kernel_config_tags_avmnet,
        avm_kernel_config_tags_last
};

#define avm_subrev_max \
        (avm_kernel_config_tags_device_tree_subrev_last - \
         avm_kernel_config_tags_device_tree_subrev_0 + 1)

struct _kernel_modulmemory_config {
        char *name;
        unsigned int size;
};

struct _avm_kernel_config {
        enum _avm_kernel_config_tags tag;
        void *config;
};

struct _avm_kernel_version_info {
    char buildnumber[32];
    char svnversion[32];
    char firmwarestring[128];
};

extern unsigned char *avm_kernel_config_device_tree[avm_kernel_config_tags_device_tree_subrev_last - avm_kernel_config_tags_device_tree_subrev_0 + 1];

#endif
vidar:~/osp.avm.de/fritzbox/fritzbox-7490 $

Ich habe mir mal erlaubt, die Namen der TAR-Member mit drei Gleichheitszeichen etwas hervorzuheben ... jedenfalls so gut es in einem Code-Block geht.

Das Programm braucht die Definitionen für die AVM-Strukturen - Du darfst also mal raten, welche der beiden Dateien hier gebraucht wurde (bei der 06.60). Kleiner Tipp von mir: Die include/linux/avm_kernel_config.h enthält nur die Definition der externen Symbole für die Pointer auf diese Strukturen und nicht deren Definitionen.

Bleibt die Frage, wo AVM die Definitionen nunmehr untergebracht hat ... und wenn man das oben gezeigte Kommando (bzw. die Kommandofolge) jetzt (u.U. mit leichten Abwandlungen) auf die nächsten Quelltext-Pakete losläßt, stellt man irgendwann fest, daß mit den Quellen der 07.01 die Definitionen aufgeteilt wurden in die reinen Struktur-Definitionen in der include/linux/avm_kernel_config.h (wo dann auch die passenden externen Symbole gleich noch definiert sind) und die enum-Variable für die "tags" in die Datei linux/include/linux/avm_kernel_config_device_tree.h gewandert ist.

Also muß man - sofern man MEIN Programm für Versionen ab 07.0x auch benutzen möchte - anstelle der linux/uapi/linux/avm_kernel_config.h nunmehr die anderen Dateien in dem entsprechenden #include-Statement verwenden. Oder man nimmt einfach eine Version des FRITZ!OS, wo sich die Definition noch an der "richtigen" Stelle befindet - wenn man (wie Du hier) nur die Funktion 64-Bit vs. 32-Bit testen will, spielt die FRITZ!OS-Version ja nur eine untergeordnete Rolle.

Wenn da also in der README.md tatsächlich etwas fehlen sollte, wäre es der Verweis auf den IPPF-Thread - wenn der dann "unbeleckten" Lesern nicht geläufig ist, mag das sogar wieder verständlich sein ... aber bei Dir KANN das gar nicht der Fall sein.

Bisher habe ich keinen Grund, da jetzt dran herumzuändern - zumal ich auch gar keinen "schlauen" Weg wüßte, wie ich die Includes "conditional" machen sollte in der avm_kernel_config_helpers.h (obendrein ist da schon eine Abhängigkeit vom Symbol "FREETZ" drin, damit das in einem Freetz-Build auch über den dort erstellten/vorhandenen Link im Verzeichnis für die Kernel-Header klappt(e) - da müßte man jetzt ein anderes Symbol suchen oder gar ein neues einführen, damit da andere Dateien inkludiert werden.

Oder man löst das dann doch wieder mit einem Patch (macht Freetz ja häufiger bzw. gerne so, hat natürlich auch seine Schattenseiten, wenn die "anchors" dann mal fehlen) - ist mir aber auch egal.

Wenn Du hier zeigen willst, daß das Problem mit meiner Version unter Deinem Fedora-System ebenso auftritt, nimm einfach eine 06.93, da liegen die Dateien noch so vor, wie die Version aus dem Repo das erwartet:

vidar:~/osp.avm.de/fritzbox/fritzbox-7490 $ tar -x -f source-files-FRITZ.Box_7490-06.93.tar.gz -z -O GPL/GPL-release_kernel.tar.gz | tar -t -v -z --wildcards "*/avm_kernel_config*"
-rw-r--r-- gjungnitz/user  946 2015-10-08 16:35 linux-3.10/include/linux/avm_kernel_config.h
-rw-r--r-- gjungnitz/user 1559 2015-10-08 16:35 linux-3.10/include/uapi/linux/avm_kernel_config.h
-rw-r--r-- gjungnitz/user 2731 2015-10-08 16:35 linux-3.10/init/avm_kernel_config.c
vidar:~/osp.avm.de/fritzbox/fritzbox-7490 $

Wobei ich mir im Moment über Deine Ziele nicht so ganz klar bin ... wenn Du schon erkannt hast, daß es an Deinem Fedora liegt und weder an "Endianess" noch an "Bitness" oder was auch immer, was erwartest Du dann genau von mir oder von @er13?

Die Aussage: "Dann nimm eben ein anderes System." wird es ja sicherlich nicht wirklich sein - aber daß es straff darauf hinausläuft, dürfte Dir doch auch klar sein, oder?

Wenn es Dir um die Bestätigung geht, daß Dein Fedora mit meinem Quelltext dieselben Probleme hat ... bitte, laß Dich nicht vom Test abhalten. Nur erwarte nicht zu viel hinsichtlich der Konsequenzen - ich werde kaum selbst hingehen und Dein System nachbauen, nur damit das dann auch unter Fedora 32 (und mit dem GCC 10, der auch praktisch "frisch" ist) funktioniert.

Mir reicht es an dieser Stelle tatsächlich aus, daß es bei meinem Tumbleweed mit GCC 9 arbeitet (das typische "works for me" - wobei der ganze Austausch hier mir dann auch ausreicht als "Warnung" an Dritte, daß es mit Fedora und/oder GCC 10 oder woran auch immer es am Ende liegt, Probleme geben könnte) - bis Du die tatsächliche Fehlerquelle in Deinem Fedora dann isoliert hast, steht Dir also noch einiges an Arbeit bevor.

Am Ende paßt ja nicht mal der Titel (so unpräzise er auch ist) so richtig zu dem, was sich hier im Verlauf herauskristallisiert hat - es handelt sich ja gar nicht um ein generelles x64- oder Endianess-Problem, denn mit anderen Systemen (die auch diese Eigenschaften haben) funktioniert es ja. Deshalb werde ich das auch umbenennen und den Hinweis auf die "spezielle Umgebung" (Fedora 32 x86_64) hinzufügen - und zwar zeitnah und nicht erst, wenn die wahre Ursache ausgemacht ist.

Stünden die ganzen Angaben zur verwendeten Umgebung bereits im ersten Kommentar, wäre diese Umbenennung auch nicht erforderlich - aber so muß man sich erst "durcharbeiten", damit man irgendwo die Feststellung findet, daß es genau mit Deinem System (meinetwegen auch verallgemeinert auf Fedora 32, was es m.W. ja auch nur noch in 64-Bit-Version gibt seit Fedora 31) nicht funktioniert.

Und auch da wäre ein weiterer Ansatzpunkt zum Eingrenzen der Ursache ... wenn das mit Fedora 31 (da war der GCC 10 noch nicht fertig) auch schon so ist, könnte man den GCC 10 als wahrscheinliche Ursache ausschließen. Alternative wäre der Test mit GCC 9.2.1 unter Fedora 32: https://fedora.pkgs.org/32/fedora-x86_64/gcc-x86_64-linux-gnu-9.2.1-3.fc32.1.x86_64.rpm.html

BTW:

Keine, wie man Namen schon erraten könnte hat das Auswirkungen auf die Toolchain, nicht die host-tools.

Ja, da hast Du tatsächlich recht ... nur macht es dann ja noch viel weniger Sinn, wenn jeder Freetz-Benutzer munter seine eigene Version des GCC auf dem Build-Host verwendet - je nachdem, wonach ihm oder dem Bearbeiter der von ihm verwendeten Distribution gerade der Sinn steht.

Also wenn man für die Host-Tools nicht auch einen Compiler mit definierter Version verwendet, den man zuerst mal mit dem ohnehin auf dem Host installierten GCC erstellt - das war es tatsächlich, was ich Freetz immer "angedichtet" hatte, weil ich in dem Irrglauben verfangen war, es würde "mehr" machen als ein gewöhnliches "buildroot" und auch für seine Host-Tools - abseits von denen, die man erst mal zum Erzeugen des GCC braucht- einen eigenen Compiler erzeugen, damit es die Host-Tools auch nicht ständig an neue GCC-Versionen anpassen muß.

Denn daß mal Defines in andere Dateien rutschen oder Sprachkonstrukte plötzlich zu zusätzlichen Warnungen führen, ist das "bread&butter"-Geschäft beim Wechsel auf eine neue Compiler-Version und/oder eine neue Kernel-Version. Aber wenn Freetz das gar nicht macht ... auch gut, muß es eben mit dem "vorgesetzten Compiler" klarkommen und wenn es das nicht tut: Schicksal, muß man eben den Compiler wechseln.

Ansonsten müßte man sich ja doch wieder auf irgendetwas als minimale und maximale Compiler-Version einigen - auch für die Host-Tools. Ich gehe ja auch nicht hin und beschwere mich, wenn sich Freetz-NG nicht mit CLang bauen läßt (wobei ich es tatsächlich auch noch nicht versucht habe - die Chancen stehen vermutlich aber trotzdem schlecht).

fda77 commented 4 years ago

Ich würd schon gern weiter Fedora einsetzen, nutze das schon seit vor der Umbenennung nach FedoraCore. Ausserdem kommen die Fehler irgendwann eh zu Ubuntu Wobei aktuell eher das Problem besteht, dass einige noch immer das uralte Freetz-Linux mit Ubuntu 14.04 von 2014 nutzen. Damit gibt es Problem mit dem Syntax von date, git, svn... Deshlab weigert sich ng neuerdingss auf einem System-Kernel v3 zu starten Von der Geschwindigkeit des x64 Systems bin ich schon überrascht. Um die ~250 genutzten fw-images zu entpacken, brauchte es nur noch ca 6 Minuten - mit x86 waren es noch 11! Waum die host-tools immmer als x86 gebaut werden weiss ich nicht. Gibt evtl einen Grund, oder es ist einfach historisch und überflüssig. Müsste man mal testen. avm_kernel_config muss auf jeden fall gleich wie dtc-host gebaut sein. Und auch einen Teil des+der kernel, die brauchen nämlich ein fcommon in den dtc-makefiles wegen gcc10... An den Thread im IPPF hatte ich nicht mehr gedacht. Weiss auch nicht mehr ab wann die 7490 einen 3er Kernel hat, davor gabs ja noch keinen devicetree. Um das Problem einzugrenzen reicht mir jedenfalls auch ein altes FOS 6.9x Habs damit nun compiliert bekommen. glibc-static.i586 fehlte noch auf dem system - freetz baut es scheinbar nicht statisch. Damit macht die compilierte Version von hier aus dem Repo leider fehlerfrei was sie soll... Hab dann deine und die Version von er13 verlgeichen. er13 scheint wohl einiges nicht übernommen oder rausgeworfen zu haben, oder auch ne Funktion von Dateiende an den Anfang verschoben, oder Variablen umbenannt Ich spicke die beiden Versionen mangels besserer Ideen mal Ausgaben um zu sehen wo es sich Unterscheidet ^^ Soll deine Version als x64 compiliert lauffähig sein (auch wenn in der Makefile m32 angegeben ist)? Überschrift: Mach wie du es am besten findest, die wirkliche Ursache ist ja nicht gefunden. Die blöde Binary vom x86 System läuft ja

PeterPawn commented 4 years ago

Die Version hier aus dem Repo ist aber auch überaltert. AVM hat irgendwann (wann genau, müßte ich erst nachsehen) die Struktur für "module memory" geändert und das berücksichtigt die Version hier noch gar nicht (die gibt dann halt nur den Namen und die gesamte Größe des zu allozierenden Speichers aus).

Ich rate mal, daß der GCC 10 irgendwelche Swaps einfach (falsch) wegoptimiert und daher eine Adresse dann nicht "umgedreht" wird. Du kannst also auch mal versuchen, das unter Fedora 32 mit dem GCC 10 ohne alle Optimierungen zu bauen und zu testen, ob es dann läuft. Das ist aber nur ein Schuß ins Blaue ...

Und für "pure 64-Bit" funktioniert die Version hier auch nicht ... dazu müßte man an der ganzen Pointer-Arithmetik (das Programm muß ja die absoluten 32-Bit-Adressen aus dem gelinkten Kernel von AVM nehmen und sie in relative (32-Bit-)Adressen umwandeln, die danach dann wieder auf die 64-Bit-Host-Adressen umgerechnet werden müssen) noch so einiges ändern. Daher ja auch der Ansatz, das als 32-Bit-Executable zu übersetzen, weil dann wenigstens die "Breite" der Pointer paßt.

fda77 commented 4 years ago

Funktioniert :D Hatte gestern noch (ne Ewigkeit) den gcc9 gebaut, damit lief es. Aber mit -O0 geht es auch mit gcc10: https://github.com/Freetz-NG/freetz-ng/commit/240587f3716f59d90413dfdb95f1871b67cc7008 Danke! Weiss nicht wie lang ich sonst gebraucth hätte das zu finden, falls überhaupt. Die Überschitft ist angepasst

Stimmt übrigens nicht ganz was ich oben über die host-tools schrieb. Richtig ist, dass manche immer als 32bit gebaut werden, aber nur die wenigsten. Der Rest ist "wie der Host"

Erweiter doch die readme von akc damit:

Wenn ich schon dabei bin, noch was ganz anderes: Wenn du am bootmanager mal was für freetz/-ng relevatnes änderst, mach doch eine issue oder push (wie https://github.com/Freetz-NG/freetz-ng/commit/7d2ec9341e24454e2de0e8fcfb5438540a1b44e4) damit es nicht untergeht

er13 commented 4 years ago

Bin nur dadurch auf diesen Thread aufmerksam geworden, dass Ihr meinen Usernamen hier erwähnt hattet.

Bei freetz-er13 werd ich keine Issue öffnen, mein letztes issue dort ist 1 Jahr her, und wurde abgewürgt. Eine "Wechselseitigkeit" gibt es nicht, wenn was von ng übernommen wurde war es meist unter eigenen Namen.

Der oben zitierte Abschnitt, konkret der Teil

wenn was von ng übernommen wurde war es meist unter eigenen Namen.

ist schlicht und ergreifend gelogen @fda77. Wenn etwas aus dem ng-Fork übernommen wurde, erfolgte dies immer mit einem Verweis auf die Original-Quelle/-Author, s. z.B.

https://github.com/Freetz/freetz/issues/89#issuecomment-475950647 https://github.com/Freetz/freetz/commit/c956c462a2e51a5d7c1ff931e300861b537ce497 https://github.com/Freetz/freetz/commit/dd85c531c1a634ab40ebef38d4ee55ba4a2073e4 https://github.com/Freetz/freetz/commit/d813c268cbf77f11a3a4cbc521e370542bed4b36 https://github.com/Freetz/freetz/commit/add45ec8e0000e8fc0bd3e74466cb13633202fb1 https://github.com/Freetz/freetz/commit/17872f5c45f9627455072f0018d9d6dde364fe7f

Und einmal habe ich mich mit dem Usernamen des Authors vertan, dies dann aber im Comment zu Commit "korrigiert" (Author lässt sich leider nicht mehr ändern, wenn etwas gepublished wurde).

https://github.com/Freetz/freetz/commit/10d0c2ecf53c02bc250da0104ce629e28fb15a12

fda77 commented 4 years ago

@er13 Ich sagte nicht dass du es warst. Wenn mal mal eine Referenz vergisst ist auch okay, passiert halt. Es geht mehr um Dinge wie

WileC's "zufällig" gewählten sed-Ausdruck Quelle: https://github.com/freetz-ng/freetz-ng/commit/b8ff421841 Kopie: https://github.com/Freetz/freetz/commit/d9b1ae83d0eb71d43795076461edcf03c1eed0c1

cawidtu's gewähtte revision im vim bump Quelle: https://github.com/freetz-ng/freetz-ng/commit/cb89e8ff7d

Why 1365? 1491 is already available. (https://github.com/Freetz/freetz/pull/194#issuecomment-500109461).

Hier frag teste du ihn sogar noch wie er genau auf diese Revision kommen würde ... ICH kann dir sagen weshalb ich diese Revision genommen hab: https://www.exploit-db.com/exploits/46973

Von diesen "Zufällen" gibts noch so einige

PeterPawn commented 4 years ago

Sorry guys ... this is MY repo and not a place for your games in the sandpit. Please look for another arena for your fights about the authority to interpret - you both have an own repo for this. Thanks.