main()-Funktion umbenennen bzw. ersetzen

Ohne dein makefile zu kennen rate ich jetzt einfach mal:
TARGET ist in deinem makefile die Variable die den Namen des Executables 
(und wahrscheinlich auch des Hex-Files) festlegt.

Danke für den Versuch, aber das ist sehr weit am Thema vorbei :-)

Was spricht gegen
main()
{
     Mymain();
}
?
Kann auch sein dass ich deine Frage falsch verstanden hab.

Sean Goff schrieb:
> Was spricht gegen
> main()
> {
>      Mymain();
> }
> ?
> Kann auch sein dass ich deine Frage falsch verstanden hab.

Aber das kostet doch ein paar Bytes vom RAM. :-)

Tipp: Da man nie zurückspringen will kann man die "verloreren" Bytes ja 
gefahrlos anderweitig wieder benutzen.

ich würde auch immer eine main nehmen,

und dort in  myMain() und die andere _main verzweigen,

Denn alle c Programme  fangen bei main an.

Sean Goff schrieb:
> Was spricht gegen
> main()
> {
>      Mymain();
> }
> ?

Mein erster Beitrag, wo ich schrub:
>Was ich nicht will, bzw. nicht geht:
>1) Mit Makros und #ifdefs zur Compilezeit zwischen zwei main()s
>umschalten. Auserdem müsste dazu bestehender Code angefasst werden.

Ok, deine Lösung hat keine Makros, aber ich muss bestehenden Code 
(nämlich die "richtige" main) umschreiben.
Alle darauffolgenden Antworten (goto etc.) bringen das selbe Problem mit 
sich.

Und ja, ich denke auch nicht dass des als gcc Parameter geht, da eben 
wahrscheinlich der StartUp-Code geändert werden muss.
Aber hätte ja sein können dass die gcc-Experten da mehr wissen :-)

Hermann-Josef schrieb:
> und was ist mit dem Umschreiben der .init9-Section?

Das ist prinzipiell möglich. Aber dann muss ich noch eine zweite Version 
des StartUp-Codes bereithalten und beim make-Aufruf gegen diese Version 
linken.
Bzw. eben per -e Parameter in die _start dieses Alternativ-StartUp-Codes 
springen.
Aber ich werde das mal weiter verfolgen, denn das geht schon sehr in die 
Richtung die ich mir vorstelle.
Der Code soll nicht angefasst werden, lediglich der Compiler-Aufruf soll 
steuern, ob main() oder myMain() aufgerufen wird.
Dann kann man sich auch bequem dafür ein extra Target im Makefile 
anlegen.

Eigentlich geht das in Ordnung. Nachteil ist, bei einem Update der 
Toolchain muss der Alternativ-StartUp-Code neu erstellt werden.

Am Bequemsten wär eben ein Linker-Flag, aber sowas gibts wohl nicht :/

Die eigentliche Frage ist doch eher, warum braucht der TO das oder meint 
es zu brauchen.
Ich wette es gibt ne bessere Lösung als ein alternatives (2.) main().

wenn schon makefile, dann würde ich im makefile zwischen zwei C-Files 
umschalten, die zum jeweiligen Projekt gehören. Beide enthalten ihr 
eigenes main(), aber nur eines der beiden wird compiliert und gelinkt, 
abhängig vom Target.

le x. schrieb:
> Der Code soll nicht angefasst werden, lediglich der Compiler-Aufruf soll
> steuern, ob main() oder myMain() aufgerufen wird.

Du musst doch den Code nicht anfassen um das mit Makros zu lösen. Und 
wie kommst du auf #ifdef?

# prog.c enthält "MyMain()":
avr-gcc -c -DMyMain=main prog.c

Udo Schmitt schrieb:
> Die eigentliche Frage ist doch eher, warum braucht der TO das oder meint
> es zu brauchen.
> Ich wette es gibt ne bessere Lösung als ein alternatives (2.) main().

Jau. Würde mich auch interessieren. Vor allen Dingen, warum dazu der 
Code nicht angefasst werden darf.
Denn eines haben diese Hintenrum-Lösungen alle gemeinsam. Zuerst hält 
man sie für eine wahnsinnig tolle Idee. Nach 3 Wochen kennt sich keiner 
mehr aus. Nach einem halben Jahr hat man den Trick schon längst wieder 
vergessen. Und nach einem 3/4 Jahr verflucht man sich selber, weil man 
bei der Reanalyse, was man da eigentlich gemacht hat, ums verrecken 
nicht mehr drauf kommt, wie und warum das eigentlich funktioniert.
Um wieviel einfacher wäre ein #define gewesen, dass man im Code 
kommentieren kann, so dass alles beisammen bleibt.

Udo Schmitt schrieb:
> Die eigentliche Frage ist doch eher, warum braucht der TO das oder meint
> es zu brauchen.
> Ich wette es gibt ne bessere Lösung als ein alternatives (2.) main().
Jaja, immer die TOs die sich einbilden, irgendwas brauchen zu würden.
Vielleicht interessiert mich eher die akademische Natur der Sache? 
Toolchain Internas, etc.

Aber OK:
Gegeben sei ein mittelgroßes Projekt (für ATmega-Verhältnisse :-)).
Dieses erstreckt sich über mehrere Module, von denen einige fertig sind, 
manche sich aber auch noch in der Entwicklung befinden.
Manchmal will man vielleicht eine neue Funktion, einen Algorithmus, eine 
Umrechnung schnell mal testen. Und zwar völlig spontan.
Nicht erst die Bedinungen herstellen die überhaupt notwendig sind damit 
diese Funktion aufgerufen wird, oder warten bis irgendwelche Ereignisse 
eintreten die diese Funktion triggern.
Kurz: Prozessor flashen, Funktion wird abgearbeitet. Schön wäre es, wenn 
man dafür ein Target hätte, die dieses Feature bereitstellt. Dann ist es 
ein Befehl in der Shell, oder ein Klick, je nach Vorlieben.
Nicht erst die main.c öffnen, irgendwas auskomentieren, Funktionsaufruf 
einfügen usw. Kurz: nicht in Sourcen rumklauben die fertig sind.
Denn mal ehrlich, wer kennt es nicht? Du entwickelst, probierst rum, 
kommentierst Dinge aus, verunstaltest existierenden Code. Und wenn dann 
alles läuft wird garantiert nicht mehr aufgeräumt...

Ich sehe auch nicht das von KHB angesprochene Problem, das man den 
Mechanismus dahinter "vergisst" und deswegen mit #defines arbeiten 
sollte.
Ganz im Gegenteil: wenn jemand meine Sourcen durchsieht muss er sich 
nicht erst fragen was denn da überall für Artefakte im Code 
rumschwirren, welche seltsamen defines die main() umhüllen, wo denn 
diese defines gesetzt werden und was noch notwendig ist um ein Feature 
zu nutzen, das er nicht braucht.
Nein, ich muss nur ein Target aus dem MF löschen und alle Spuren meines 
Workarounds sind verschwunden.

Auch wenn manchen die Fantasie vielleicht fehlt, wo hier der konkrete 
Nutzen wäre: ich hätte einen, und zwar erheblich.
Leider wird sich nun die Diskussion in eine völlig andere Richtung als 
meine ursprüngliche Frage entwickeln. Aber ich denke, ich hab meine 
Antwort eh schon :-)

Viele Grüße!

> Mit #define und #if im Originalcode herumzufuhrwerken ist nicht die
> Lösung.

Natürlich nicht. Das predige ich ja selbst schon seit Beginn an :-)

>
> Kein Versionskontrollsystem?! Ich würde einfach meinen Testaufruf in die
> main.c machen, diese aber dann nicht einchecken und nötigenfalls
> zurücksetzen.

Doch natürlich, benutze hier git.
Klar geht das, aber ich wünsche mir halt immer noch irgendwie die 
Ein-Klick-Lösung (respektive ein-Kommando).

Mir ist aber noch was gekommen, das werd ich so mal testen:
Ganz normal Kompilieren, aber vorm Linken mittels strip das Symbol 
"main" aus der main.o entfernen.
Meine zu testende Funktion muss dann natürlich main() heißen oder von 
einer dummy-main() aufgerufen werden, aber das ist noch tragbar, da sich 
das alles innerhalb der aktuellen c-Datei abspielt. Evtl. kann man diese 
Funktion kurz im Quelltext kennzeichnen, etwa so wie die avr-libc das 
mittels ISR macht. Das Ganze kann man dann in einem Header verstecken.

le x. schrieb:
> Kurz: Prozessor flashen, Funktion wird abgearbeitet. Schön wäre es, wenn
> man dafür ein Target hätte, die dieses Feature bereitstellt. Dann ist es
> ein Befehl in der Shell, oder ein Klick, je nach Vorlieben.

Dann schreibe doch gleich, dass Du so etwas haben willst. Stattdessen 
führst Du alle Mitleser und -schreiber absichtlich in die Irre, indem Du 
eine komplett andere Frage stellst.

Die Lösung ist nämlich viel, viel einfacher als sämtliche Basteleien mit 
Präprozessordirektiven oder Eingriffen in den Startvorgang: man erstelle 
einfach mehrere Quelltexte, in denen die entsprechenden 
main()-Funktionen implementiert sind. Und im Makefile oder der IDE 
konfiguriert man eben mehrere Targets, in denen die Kompilate der 
unterschiedlichen Quelltexte angezogen werden. Fertig ist die Laube.

Informiere dich mal über "test driven development".
Schreibe dir halt für einzelne Funktionen und Module eigene Tests die 
jeder ein main haben.
Die Tests kannst du dann bei jeder Änderung am Code wieder benutzen, 
bzw. bei einer Portierung mit portieren und kannst damit sofort das 
portierte testen.
Braucht nur etwas Organisation und schon kannst du die gesamte Frickelei 
weglassen.

le x. schrieb:
> Jaja, immer die TOs die sich einbilden, irgendwas brauchen zu würden.
Nein, immer die TOs, die meinen ihr kruder Ansatz wäre der einzige Weg.

lex schrieb:

>> man erstelle einfach mehrere Quelltexte, in denen die entsprechenden
>> main()-Funktionen implementiert sind. Und im Makefile oder der IDE
>> konfiguriert man eben mehrere Targets, in denen die Kompilate der
>> unterschiedlichen Quelltexte angezogen werden.
>
> Viel, viiieel mehr Aufwand als wenn man die main() ändern könnte.
> Mehrere Quelltexte mit einer main()? Und dann noch mehrere Targets? Für
> was? Brauch ich nicht, für das was ich will. Auch viel mehr Arbeit als
> meine Methode mit strip.

Aber straight forward und wäre schon längst fertig, wenn du um 13:00 
angefangen hättest.

le x. schrieb:
> Nicht erst die main.c öffnen, irgendwas auskomentieren, Funktionsaufruf
> einfügen usw. Kurz: nicht in Sourcen rumklauben die fertig sind.
Darum eigene Testprogramme

lex schrieb:
> Module Tests? Wo hab ich denn sowas geschrieben?
Gar nicht, ich bin idealistischerweise davon ausgegangen, daß du bereit 
bist was neues zu lernen.

lex schrieb:
> Ist klar dass es für jedes Problem 1000 mögliche Lösungen gibt.
Gute und weniger gute, du scheinst dich für weniger gute zu entscheiden.

Viel Spass damit solange du Software nicht mal professionell entwickeln 
musst.

Würdest du denn beim Testen gerne angeben können, welche Funktion nun 
anstelle der main() angesprungen wird, oder soll es einfach quasi eine 
main2() Funktion geben, die immer die selbe ist?

lex schrieb:
> Und dabei wollt ich doch nur kurz und unkompliziert z.B. meine
> atoi()-Implementierung testen...

Diese atoi() Funktion wird ja vemutlich Parameter und Rückgabewert haben 
(und auch wenn nicht, es könnte mal eine Funktion geben, die du testen 
möchtest, die Parameter und Rückgabewert haben), oder? Dann bringt dir 
das direkte Anspringen dieser Funktion ja nicht viel, da du dann weder 
Parameter übergeben, noch den Rückgabewert überprüfen kannst.

Also müsstest du für jede zu testende Funktion auch eine eigene 
main()-Funktion machen, die dann die zu testende Funktion mit diversen 
Parametern auf korrekte Arbeitsweise überprüft (was ja wie schon erwähnt 
Richtung Modultests geht).

Oder sollen deine zu testenden Funktionen immer nur void foo(void) 
Funktionen ohne Parameter und Rückgabewert sein?

lex schrieb:

> Kann man mit gcc eine andere Funktion außer main() als erste C-Funktion
> anspringen?

Lege die Funktion per section Attribut nach .init8 und gut is.

Udo Schmitt schrieb:
> Die eigentliche Frage ist doch eher, warum braucht der TO das oder meint
> es zu brauchen.

Genau so ist es.

> Ich wette es gibt ne bessere Lösung als ein alternatives (2.) main().

Da verwett ich meinen A... drauf ;-)

lex schrieb:
> Soll ich dir verraten, in welche Fahrzeuge du zukünftig lieber nicht
> mehr einsteigen solltest?

Ich steige nur in Autos die mindestens schon 3 Jahre im Markt sind. Bis 
dahin haben deine Kollegen deine Fehler gefunden :-)

Udo Schmitt schrieb:
> le x. schrieb:
>> Jaja, immer die TOs die sich einbilden, irgendwas brauchen zu würden.
> Nein, immer die TOs, die meinen ihr kruder Ansatz wäre der einzige Weg.

Ihre Anzahl ist Legion.

So wie der Kollege, der selber ein Faxgerät entwickeln will, weil ihm 
andere Lösungen zu teuer sind. Mann Mann Mann...

Udo Schmitt schrieb:
> Ich steige nur in Autos die mindestens schon 3 Jahre im Markt sind. Bis
> dahin haben deine Kollegen deine Fehler gefunden :-)

Owned. :)

Und in GNU-C gibt's auch attribute constructor, mit dem man Funktionen 
vor main() ausführen kann.  Diese Constructors werden zum Zeitpunkt 
ausgeführt wie statische C++ Konstruktoren auch.

Nein, der Constructor liegt eben nicht in der .init-Section; er wird nur 
von dort aus aufgerufen.  Der Unterschied ist, dass er deshalb nicht 
naked sein darf im Gegensatz zu "normalen" init-Funktionen, die naked 
sein müssen und daher begrenzten Funktionsumfang haben.  Für letztere 
ist nur das Funktionieren von Inline-Assembler garantiert.