Aenderungen in .c vs. aenderungen im .o

OP #4672697 
Moin,

Hab' hier gerade einen - hm - fuer mich erstaunlichen Effekt.
Ich hab' ein .c file; in dem kommt sowas vor:

1
#if 0

2
static int64_t bla;

3
//printf("ts=%lld\n",timestamp-bla);

4
if (timestamp-bla<=0) printf("----------------------------------\n");

5
bla=timestamp;

6
#endif


Da haette ich in meinem jugendlichen Leichtsinn gedacht, wenn ich da 
z.b. die eh' auskommentierte Zeile mit dem printf("ts=... loesche und 
neu compiliere, dann sollte das zu keinen Aenderungen im .o file 
fuehren.
Tuts aber. Lass' ich mir die .o files in beiden Faellen mittels objdump 
-d disassemblieren und diffe die daraus entstehenden Assemblerlistings, 
dann haben die an einigen Stellen bei bedingten Spruengen veraenderte 
Werte. Aber auch in irgendwelchen "nicht-.text" Bereichen.
Warum?

Gruss
WK
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
OP 
Moin,

Clemens L. schrieb:
> Zeilennummern in den Debug-Informationen.
Hm. Naja. Dann waeren die .o files unterschiedlich. Aber warum dann die 
unterschiedlichen Adressen bei den Spruengen?
Allzuviel debug wird nicht drinnensein, ein objdump -g liefert nur:
filename.o:    file format elf32-littlearm


> Hast du für die anderen Änderungen ein konkretes Beispiel?

Symboltabelle:

0000319c l     F .text  000011e8 name_einer_funktion
vs.
0000319c l     F .text  000011ec name_einer_funktion

OK, das wird wohl die selbe Baustelle sein. Eine Funktion hat sich um 4 
Byte verschoben. Innerhalb dieser Funktion wurden andere Funktionen 
ge-inlined; in einer davon war die ominoese src-code Aenderung.
Weiterhin im Disassembly an vielen Stellen Dinger von dem Kaliber:
    25d4:   00000058    .word   0x00000058
    25d8:   00000756    .word   0x00000756
    25dc:   00000190    .word   0x00000190
vs.
    25d4:   00000058    .word   0x00000058
    25d8:   00000757    .word   0x00000757
    25dc:   00000190    .word   0x00000190


Erstaunlich halt, dass trotz #if 0 und // die Zeile so einen Einfluss 
hat.

Gruss
WK
Antwort Zitieren Bearbeiten Löschen Melden Danke
OP 
Moin,

Johann L. schrieb:
> Sieht der erzeugte Assembler-Code (mit -save-temps -g0) denn
> anders aus?

Ich hab' mal auf die Schnelle reingeguckt, die .word Geschichten sehen 
da dezimal etwas aufschlussreicher aus. Muss ich naechste Woche nochmal 
intensivieren.

Markus F. schrieb:
> # man gcc
> /-frandom-seed

Isses glaub' ich eher weniger. Mehrfache Builds aus den selben sourcen 
liefern auch identische .o files.

Gruss
WK
Antwort Zitieren Bearbeiten Löschen Melden Danke
OP 
Moin,

Hab' den Uebeltaeter. In dem Code kommen Aufrufe zu einem debug-printf 
Macro vor, in dem kommt auch "__LINE__" vor. Und das veraendert sich 
natuerlich, wenn ich eine Zeile loesche, egal ob die der Praeprozessor 
ueberhaupt liest oder ob's ein Kommentar ist.
Einer der Unterschiede in beiden Faellen war so ein Konstrukt, das nur 
in einem Fall vorkam und im anderen Fall gefehlt hat:

.word 709

In der Zeile 709 ist dann in dem Fall so ein debug macro; das ist sonst 
eine Zeile verrutscht, und dann hat der gcc sich die Konstante 708 eben 
anders erzeugt als 709...

Merci fuer die Tipps; insbesondere an c_l!

Gruss
WK
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 10 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.