Discussion :

[_C_Newbie]

Salut tout le monde;

Je me suis mis dans la programmation bare metal sur le raspberry.
En compilant ce petit bout de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 char buf[100];
 //===================================================
 
void fill()	 { // fill buffer with ASCII characters
	int i,c=0;
	char mystr[14] = "hello world !!";
	for (i=0;i<100;i++) {
		buf[i] = mystr[c++];
		if (c > 13) c = 0;
	}
}
//====================================
int main(){
  fill();
return 0;
}

J'obtiens ce mesage:

main.c: ( .text+...): undefined reference to `memcpy'

les options passés à GCC (arm-none-eabi):

-O0 -nostdlib -nodefaultlibs


Une question sur la marge:
Pour un processeur 32bits , est-ce que je dois m'occuper moi-même de types des varibales (char, int ...) ou c'est le compilateur qui s'en occupe?
J'aimerais bien, svp, me guider vers des tutos sur le sujet.

Merci

[Matt_Houston]

Solution de contournement : essaie sans la ligne char mystr[14] = "hello world !!"; (trouve une autre méthode pour remplir le buffer).

[_C_Newbie]

trouve une autre méthode pour remplir le buffer.

Merci Matt pour la réponse très rapide!!
Comment contourner le probleme de remplissage?
Sinon comment écrire une fonction "memcpy" personnelle très simple?

[Matt_Houston]

Comment contourner le probleme de remplissage?

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
mystr[0] = 'h';
mystr[1] = 'e';
mystr[2] = 'l';
...

En espérant que ça dissuade le compilo de mentionner memcpy.. Hé oui.

Sinon comment écrire une fonction "memcpy" personnelle très simple?

C'est à très peu de choses près ce que tu as écrit dans la fonction fill !

[_C_Newbie]

C'est à très peu de choses près ce que tu as écrit dans la fonction fill !

Merci encore Matt.

c'est résolu avec ce p'tit bout de code (trouvé sur le web) !!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
void memcpy(void *dest, void *src, int n)
{
	int i;
   // Typecast src and dest addresses to (char *)
   char *csrc = (char *)src;
   char *cdest = (char *)dest;
 
   // Copy contents of src[] to dest[]
   for ( i=0; i<n; i++)
       cdest[i] = csrc[i];
}

Mais pourquoi le compilateur utilise des fontions standard malgrès l'option "-nostdlibs" ???

[picodev]

Salut tout le monde;

Je me suis mis dans la programmation bare metal sur le raspberry.
En compilant ce petit bout de code:
[...]
J'obtiens ce mesage:

main.c: ( .text+...): undefined reference to `memcpy'

les options passés à GCC (arm-none-eabi):

-O0 -nostdlib -nodefaultlibs


Une question sur la marge:
Pour un processeur 32bits , est-ce que je dois m'occuper moi-même de types des varibales (char, int ...) ou c'est le compilateur qui s'en occupe?
J'aimerais bien, svp, me guider vers des tutos sur le sujet.

Merci

Bonjour,
memcpy est une fonction de la bibliothèque standard, l'option -nostdlib demande à gcc de ne pas lier l'exécutable avec la bibliothèque standard → normal que ça ne fonctionne pas.

[Matt_Houston]

memcpy est une fonction de la bibliothèque standard, l'option -nostdlib demande à gcc de ne pas lier l'exécutable avec la bibliothèque standard → normal que ça ne fonctionne pas.

L'OP n'invoque pas memcpy explicitement.

Mais pourquoi le compilateur utilise des fontions standard malgrès l'option "-nostdlibs" ???

Aucune idée, j'imagine que c'est contrôlé par une autre option..

[_C_Newbie]

memcpy est une fonction de la bibliothèque standard, l'option -nostdlib demande à gcc de ne pas lier l'exécutable avec la bibliothèque standard → normal que ça ne fonctionne pas.

Oui, mais moi j'ai pas demandé au compilateur d'utiliser "memcopy" !!
J'ai fourni ma méthode pour remplir le buffer.

[picodev]

L'OP n'invoque pas memcpy explicitement.




Aucune idée, j'imagine que c'est contrôlé par une autre option..

Oui, mais moi j'ai pas demandé au compilateur d'utiliser "memcopy" !!
J'ai fourni ma méthode pour remplir le buffer.

Parce que c'est écrit dans la doc de gcc →

-nostdlib
Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify are passed to the linker, and options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, are ignored.
The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.

One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines which GCC uses to overcome shortcomings of particular machines, or special needs for some languages. (See Interfacing to GCC Output, for more discussion of libgcc.a.) In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GCC library subroutines. (An example of such an internal subroutine is __main, used to ensure C++ constructors are called; see collect2.)

→ ajouter -lgcc

[_C_Newbie]

ajouter -lgcc

Cette option ne resout pas le probleme !!
Tjrs la même erreur.

[picodev]

Du coup comme tu l'as fait et comme c'est préconisé : « These entry points should be supplied through some other mechanism when this option is specified.»
Tu fournis ta version des fonctions manquantes et nécessaires.

D'autres possibilités incluent d'essayer les options -fno-builtin (à vérifier), et -ffreestanding (une bonne piste à mon avis).

[_C_Newbie]

D'autres possibilités: -fno-builtin et -ffreestanding .

Que dalle, nada, walou ..... !!

[_C_Newbie]

Avec Yagarto (sous WIN) le probleme ne se pose pas. J'ai essayé .
Est-ce qu'on peut considérer le probleme comme résolu et fermer la discussion?

[picodev]

Que dalle, nada, walou ..... !!

J'ai parlé de possibilité, il faut donc lire la doc un peu plus intensivement, chercher sur le net, etc.

Avec Yagarto (sous WIN) le probleme ne se pose pas. J'ai essayé .
Est-ce qu'on peut considérer le probleme comme résolu et fermer la discussion?

Pour fermer la discussion le plus simple est que tu la marques comme résolue Tu es maître de ton fil.

[_C_Newbie]

J'ai parlé de possibilité, il faut donc lire la doc un peu plus intensivement, chercher sur le net, etc.
.

Pour moi c'est pas encore résolu, je vais essayer de trouver la solution.
Mais je me contente de solution disponible pour le moement (fournir une fonction memcpy).
Merci encore Picodev et Matt.

[Médinoc]

Pour moi c'est pas encore résolu, je vais essayer de trouver la solution.
Mais je me contente de solution disponible pour le moement (fournir une fonction memcpy).

Si j'en crois la doc citée par Picodev, c'est la solution.
La doc dit explicitement que le compilateur peut générer des appels à memcpy() et consorts (ici, pour initialiser un buffer sur la pile à chaque appel de la fonction), et que donc si tu utilises -nodefaultlib tu dois lui fournir ces fonctions autrement.

Par contre, si tu veux que l'appel ne soit pas généré, il te suffit d'éviter d'avoir un buffer sur la pile initialisé ainsi à chaque appel de la fonction. Dans le cas de fill() c'est facile, puisque tu ne modifies pas la chaîne:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void fill()	 { // fill buffer with ASCII characters
	int i,c=0;
	char const *mystr = "hello world !!"; //Et hop, ce n'est plus un buffer qu'on initiailise à chaque appel, mais une chaîne statique!
	for (i=0;i<100;i++) {
		buf[i] = mystr[c++];
		if (c > 13) c = 0;
	}
}