Assembler Includes nach C

Gast #4585865
Lesenswert?

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:
1
/* OS/include/generated/.asm-defines.s */
2

3
  .ascii  "__BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__\000"
4
.LASF98:
5
  .ascii  "__INT32_C(c) c\000"
6
.LASF16:
7
  .ascii  "__SIZEOF_INT__ 4\000"
8
.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?
Persönliche Seite #4585886
Lesenswert?

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
1
gcc -g3 -save-temps ...
und schau ins .s File.
Gast #4586811
Lesenswert?

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...
1
./../../toolchains/arm-linux-gnueabihf/libc/usr/include/stdio.h:443:24:
2
error: redundant redeclaration of ‘fscanf’ [-Werror=redundant-decls]
3
 extern int __REDIRECT (fscanf, (FILE *__restrict __stream,
4
                        ^
5
./../../toolchains/arm-linux-gnueabihf/libc/usr/include/sys/cdefs.h:178:41:
6
note: in definition of macro ‘__REDIRECT’
7
 # define __REDIRECT(name, proto, alias) name proto __asm__ (__ASMNAME (#alias))
8
                                         ^
9
./../../toolchains/arm-linux-gnueabihf/libc/usr/include/stdio.h:425:12:
10
note: previous declaration of ‘fscanf’ was here
11
 extern int fscanf (FILE *__restrict __stream,
12
            ^


Macht man das so, einfach auf den include der Toolchain verweisen?
Gast #4587198
Lesenswert?

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:
1
#ifndef _ENDIAN_H
2
# error "Never use <bits/endian.h> directly; include <endian.h> instead."
3
#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.
Persönliche Seite #4587221
Lesenswert?

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?=

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren