Aenderungen in .c vs. aenderungen im .o

Dergute W. #4672697
Lesenswert?
• ▲
▼ 
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 Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Dergute W. #4672817
Lesenswert?
• ▲
▼ 
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 Beitrag melden
Dergute W. #4672992
Lesenswert?
• ▲
▼ 
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 Beitrag melden
Dergute W. #4675456
Lesenswert?
• ▲
▼ 
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 Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren