Aenderungen in .c vs. aenderungen im .o

[Dergute W. (derguteweka)]

Moin,

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

#if 0
static int64_t bla;
//printf("ts=%lld\n",timestamp-bla);
if (timestamp-bla<=0) printf("----------------------------------\n");
bla=timestamp;
#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

[Clemens L. (c_l)]

Zeilennummern in den Debug-Informationen.

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

[Dergute W. (derguteweka)]

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

[Clemens L. (c_l)]

Dergute W. schrieb:
> 0000319c l     F .text  000011e8 name_einer_funktion
> 0000319c l     F .text  000011ec name_einer_funktion
>
> OK, das wird wohl die selbe Baustelle sein. Eine Funktion hat sich um 4
> Byte verschoben.

Weil irgend etwas davor jetzt größer ist. Kannst du herausfinden, was?

[Dergute W. (derguteweka)]

Moin,

Es scheint mir so eines dieser .word 0xXXXXXXXX statements zu sein, was 
da mehr reingerutscht ist.
Bin mir nicht sicher; ich dachte, dass da irgendwelche Konstanten 
drinnenstehen, die dann relativ zum PC geladen werden koennen...

Gruss
WK

[Johann L. (gjlayde)]

Sieht der erzeugte Assembler-Code (mit -save-temps -g0) denn anders aus?

[Markus F. (mfro)]

# man gcc
/-frandom-seed

[Dergute W. (derguteweka)]

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

[Kaj (Gast)]

Compilier doch mal mit -s

[Dergute W. (derguteweka)]

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