Assembler Includes nach C

[olpo (Gast)]

Hallo,


ich schreibe gerade eine App für ein kleines OS.
Leider vermisse ich saubere include/ Header-files, die ich fuer meine 
App benutzen kann.

In dem OS-Verzeichnis habe ich nur ein ASM-Datei:

/* OS/include/generated/.asm-defines.s */

  .ascii  "__BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__\000"
.LASF98:
  .ascii  "__INT32_C(c) c\000"
.LASF16:
  .ascii  "__SIZEOF_INT__ 4\000"
.LASF872:

Kann ich diese .asm-defines.s in meinem C-Programm verwenden?

Ist das schön, sinnvoll oder evtl. sogar so gedacht diese ASM als 
include zu verwenden?

[Johann L. (gjlayde)]

olpo schrieb:
> Kann ich diese .asm-defines.s in meinem C-Programm verwenden?

Nein.

> sinnvoll oder evtl. sogar so gedacht diese ASM als
> include zu verwenden?

Nein.

Sieht aus wie von DWARF-3 oder höher erzeugte Debug-Info; in einem 
ASM-Programm kannst du damit nichts anfangen, und in einem C-Programm 
ist das auch nutzlos oder sogar falsch.

Solche Debug-Einträge werden vom Compiler erzeugt, übersetz einfach mal 
ein C-Modul oder -Programm mit

gcc -g3 -save-temps ...

und schau ins .s File.

[olpo (Gast)]

Danke,


da das OS keine System-Header bereitlegt, habe ich einfach mal auf den 
Include-Pfad der Toolchain verwiesen. Dort werden Sachen wie BYTE_ENDIAN 
definiert.

Ich bin mir aber nicht sicher, ob das so gedacht und sauber ist;
denn der Compiler wirft einen Werror.
Die CPP-Flags sehen eigentlich richtig aus...

./../../toolchains/arm-linux-gnueabihf/libc/usr/include/stdio.h:443:24:
error: redundant redeclaration of ‘fscanf’ [-Werror=redundant-decls]
 extern int __REDIRECT (fscanf, (FILE *__restrict __stream,
                        ^
./../../toolchains/arm-linux-gnueabihf/libc/usr/include/sys/cdefs.h:178:41:
note: in definition of macro ‘__REDIRECT’
 # define __REDIRECT(name, proto, alias) name proto __asm__ (__ASMNAME (#alias))
                                         ^
./../../toolchains/arm-linux-gnueabihf/libc/usr/include/stdio.h:425:12:
note: previous declaration of ‘fscanf’ was here
 extern int fscanf (FILE *__restrict __stream,
            ^

Macht man das so, einfach auf den include der Toolchain verweisen?

[Rufus Τ. F. (rufus)]

Könnte es sein, daß das die internen Include-Dateien sind, die zum Bauen 
der libc erforderlich sind, und nicht die, die das externe Interface der 
libc definieren? So etwas wie "__REDIRECT" hat in einer stdio.h nichts 
zu suchen.

[Johann L. (gjlayde)]

olpo schrieb:
> da das OS keine System-Header bereitlegt, habe ich einfach mal auf den
> Include-Pfad der Toolchain verwiesen.

Was meinst du mit "verweisen"? Die Systempfade sind der Toolchain 
bekannt, da muss man nix "einfach mal" so machen.

[olpo (Gast)]

Rufus Τ. F. schrieb:
> Könnte es sein, daß das die internen Include-Dateien sind, die zum Bauen
> der libc erforderlich sind, und nicht die, die das externe Interface der
> libc definieren? So etwas wie "__REDIRECT" hat in einer stdio.h nichts
> zu suchen.

Also, ich habe den Pfad zu meinen 'INCDIRS' (-I...) aufgenommen, weil 
der Compiler 'endian.h' nicht kannte.
Die findet sich aber zweimal in der Toolchain:

./arm-linux-gnueabihf/libc/usr/include/bits/endian.h
./arm-linux-gnueabihf/libc/usr/include/endian.h

Wobei in der bits/endian.h steht:

#ifndef _ENDIAN_H
# error "Never use <bits/endian.h> directly; include <endian.h> instead."
#endif

Deshalb habe ich gedacht, es wäre in Ordnung 'libc/usr/include' in 
meinen Include-Pfad aufzunehmen. Sicher bin ich mir aber nicht, ob das 
cool ist.

[Johann L. (gjlayde)]

olpo schrieb:
> Deshalb habe ich gedacht, es wäre in Ordnung 'libc/usr/include' in
> meinen Include-Pfad aufzunehmen. Sicher bin ich mir aber nicht, ob das
> cool ist.

Planlosigkeit ist nie cool ;-)

WENN der entsprechende Pfad zu den System-Includes gehörte, dann wäre er 
dem Compiler BEKANNT.

Warum includest du endian.h wenn es nicht Teil deines Projekts ist?

Ein IS zu generieren kann ziemlich tricks sein.  Hast du dessen 
Build-Doku gelesen und verstanden?=