Test case qui renvoie "Corrupted program" - Page 1

yop,

Sous AMS 2.09, le dernier PreOS, un programme compilé avec la denière version de GCC4TI :

build :

tigcc -v -O2 -Wall -W --cut-ranges --optimize-code --remove-unused --optimize-relocs --merge-constants --reorder-section \
  truc.c   \
  machin.c   \
  -o bidule 2>> log

truc.c

#include  "kernel.h"
#include  "funcs.h"

void main(void)
{
  clrscr();
  ESI ArgPtr = top_estack;

  if (*ArgPtr == END_TAG)
  {
    CommandHelp();
    return;
  }
}

machin.c

#include "kernel.h"
#include "funcs.h"
void CommandHelp(void)
{
  printf("abc");
  ngetchx();
}

Dans ce cas là, tout marche bien.
Maintenant, si je rajoute "const char* HelpText" dans machin.c, j'ai un Corrupted program au runtime. Le binaire fait 4 octets de plus, et je ne sais pas ce qui merde.

Mon but étant de passer évidemment HelpText à printf et non "abc", c'est mal emmanché pour le moment.

Une idée ?

Tu peux mettre la source que ça donne après la modification qui casse tout ?

machin.c 
 
#include "kernel.h" 
#include "funcs.h" 

+ const char* HelpText;

void CommandHelp(void) 
{ 
  printf("abc"); 
  ngetchx(); 
}

Sans le '+' évidemment.

C'est marrant ça

bon je sais pas si c'est ça mais si tu dis "const char *" c'est qu'on attend que tu mettes des données.

ok ça devrait pas faire planter mais bon.

essaye ça:

machin.c 
 
#include "kernel.h" 
#include "funcs.h" 

const char* HelpText="turlututu";

void CommandHelp(void) 
{ 
  printf("%s",HelpText); 
  ngetchx(); 
}

Sans printf(UneVariable) évidemment

Merci, je vais essayer.

Tiens, question : pourquoi mets-tu :

printf("%s",HelpText)
et non
printf(HelpText) ?

printf attend un const char*, et HelpText en est un.

Par contre, quand je regarde le code assembleur, si j'écris
printf(HelpText);
il me sort ça :
move.l HelpText,(sp)

Ce qui est évidemment faux, il faut pousser l'adresse et non le contenu de la chaine.

Je mets donc un
printf(&HelpText);
Là ok, il me sort ça :
pea HelpText

Et c'est bien ce que j'attends !

Par contre, il me balance un warning : "Passing argument 1 of printf from incompatible pointer type". Ca peut se comprendre, HelpText est du bon type et donc pas &HelpText, mais c'est pourtant avec ça que le code généré est bon !

Là je coince, je demande une explication

Folco (./6) :
printf("%s",HelpText)
et non printf(HelpText) ?

Exercice : que se passe-t-il dans le second cas si la chaîne HelpTest contient un backslash (ou pire, un signe pourcentage) ?

En effet printf(HelpText) représente une belle faille de sécurité. ^^

Sauf si HelpText est codé par moi en dur

ça change rien, suffit de changer l'adresse de ta variable

et dans ce cas tu l'écris directement en plus

Et ça change rien à mon problème de type et de warnings du ./6 que je comprends toujours pas

bah si, printf attend const char* en premier arg, si tu lui files &(Hello) et que hello est un const char*, le résultat est un const char ** donc warning mauvais type.

pour faire mieux faudrait écrire printf( (const char*)(&Hello) ) ce qui forcerait le type et éviterait le ouarningue, mais explique pas pkoi l'asm est mauvais.


mais en fait ça c'est juste:

printf(HelpText);
il me sort ça :
move.l HelpText,(sp)


oublie pas que HelpText est une variable pointeur, donc le contenu de la mémoire à l'adresse HelpText contient l'adresse de la chaine

quand tu fais de l'asm et que t'écris:

Helptext: .ascii "prout"

en fait c'est comme si tu déclarais un tableau de char:

const char Helptext[]="prout";

et quand tu fais lea Helptext, ça fait &(HelpText[0]), parce que lea <ea> est equivalent à &(<ea>)

et que si tu fais move Helptext,%d0, %d0 va contenir *(HelpText)


enfin bref toujours la même magouille et le pb des variables C et des symboles ASM qui correspondent à des adresses en asm, mais a des vraies variables en C, parce que justement le move direct,ea fait un dereferencement de direct.

han, HelpText doit donc être un const char** alors ?

non non relis moi j'ai crossédité.

la magouille c'est que toutes les variables en C sont en RAM, donc elles sont toutes en accès move direct, ... ou move ..., direct

int a = 3;
int *b = &a;

ça fera en asm
a: .long 3
b: .long a

l'opération int a = 3 ça fait pour un assembleux 3 ->mem[a] (move a,3) et pas 3->a
par contre int *a = 3, ça fait pour un assembleux 3->a, ce qui est pas possible "tel quel" en asm car a est un label/symbole, donc pas changeable
et int b=*a ça fait mem[mem[a]]->mem[b ] (move a, (b) )

du coup on a été obligé d'inventer les variables pointeurs qui puissent contenir l'adresse d'autres variables

Ouep, c'est bien beau tout ça, tu as raison c'est chiant.

Mai j'ai toujours pas trouvé la solution académique pour virer ces warnings

Tu supprimes le flag -W. ^^

mais il était bon ton code. T'as essayé de l'exécuter? ^^

char *plop = "pwet";
void func() {
  printf("%s",plop);
}

void foobarbaz() {
  printf(plop); // sale mais bon on s'en accomodera
}

geo²: c'est cela, oui

En effet le
printf("%s", plop) est la meilleure solution mais un
printf((const char*)plop); fonctionne tout aussi bien (malgré que cela soit moins propre).

c'est pas le pb.

Folco: regarde bien ce qui est généré par tigcc

#include <stdio.h>

char *plop = "pwet";

.LC0:
	.ascii "pwet\0"
	.even
plop:
	.long	.LC0
.LC1:
	.ascii "%s\0"
	.text
	.even
	.globl	boo

void boo() {
	printf("%s",plop);
}

boo:
	link.w %fp,#0
	move.l plop,%d0
	move.l %d0,-(%sp)
	pea .LC1
	jbsr printf
	addq.l #8,%sp
	unlk %fp
	rts
	.even
	.globl	far

void far() {
	printf(plop);
}

far:
	link.w %fp,#0
	move.l plop,%d0
	move.l %d0,-(%sp)
	jbsr printf
	addq.l #4,%sp
	unlk %fp
	rts

op: .long .LC0

je fais un zoom:.LC0:
	.ascii "pwet\0"
	.even
pl

toi tu as l'habitude de faire pea .LC0
mais regarde mieux: plop contient l'ADRESSE de .LC0
Du coup il fait pas faire pea plop, mais bien move plop, %d0

c'est cuefdé!

PS: on remarque que comme on l'a explicitement demandé, le compilo pisse une variable supplémentaire "plop" qui contient l'adresse de .LC0
Et tu remarques que le "%s" est une valeur "anonyme en C", et là il fait direct pea .LC1 puisqu'il n'a pas besoin de son adresse!

PPS: pareil avec -O3

	.globl	far
far:
	move.l plop,-(%sp)
	jbsr printf
	addq.l #4,%sp
	rts
	.section	.rodata.__unalignedstr,"dmu"
.LC0:
	.ascii "%s\0"
	.text
	.even
	.globl	boo
boo:
	move.l plop,-(%sp)
	pea .LC0
	jbsr printf
	addq.l #8,%sp
	rts
	.globl	plop
	.section	.rodata.__unalignedstr,"dmu"
.LC1:
	.ascii "pwet\0"
	.text
	.even
plop:
	.long	.LC1

Ah ok, c'est cool merci bien.

Pas contre, j'avais auto-zoomé sur ça moi :

	move.l plop,%d0 
	move.l %d0,-(%sp) 

compilé sans optim, et cross posté la version -O3 ^^

Oué bon, ça génère toujours pas ça chez moi :
const char InvalidCall[] = "Invalid call"

const char* InvalidCall;
	if (ArgCount == 2)
	{
		printf(InvalidCall);
		ngetchx();
		return;
	}

	cmp.w #2,%d0
	jbne .L10
	move.l InvalidCall,-(%sp)
.L11:
	jbsr printf
	jsr _ROM_CALL_51:l

	.globl	InvalidCall
	.section	.rodata.InvalidCall,"d"
InvalidCall:
	.ascii "Invalid call.\0"

c'est bien pour ça que j'ai écrit

const char * InvalidCall = "invalid call";

et pas

const char InvalidCall[] = "truc";

J'ai changé, c'était écrit const char* avant. Mais je me décourage pas, je réessaye, parce que j'aime me prendre des beignes dans la gueule

edit -> c'est bien ça, j'ai toujours de l'assembleur invalide à la sortie

mais t'as essayé de l'exécuter ou pas

d'après moi il est valide cet asm, j'ai au grand jamais eu de problèmes avec print sur ti68k!!

Pas essayé, non. Je vois pas pourquoi ça marcherait si l'assembleur est invalide, à moins que j'ai pas vu le patcheur à chaud fourni par GCC4TI

Ben quand j'exécute ça, j'ai un "Corrupted program", pourtant mon code a bien changé depuis hier soir.

Bon, ben j'ai casté avec un (const char*), j'ai toujours un "corrupted program". J'ai plus qu'à me retrousser les manches direction le code de PedroM pour voir ce qui peut provoquer une telle erreur

Bon, ras le fion, un e-bisou à qui m'aidera à trouver la solution. Je continue à coder, mais c'est chiant de pas comprendre, j'aime pas ça
Fichier joint : asti68k_c.7z

essaye sur ams ou vti si possible.