J'utilise un processeur RISCV (RV32). Avec un certain code que j'ai écrit dessus, j'ai remarqué quelque chose d'étrange. Lorsque j'utilise l'instruction "JAL" ou l'instruction "J" pour passer à une adresse spécifique, il semble que le décalage n'est pas calculé correctement.
Disons que j'ai du code (pram_resetvector) situé à l'adresse 0x00008080, je veux sauter à.
Le code de saut semble comme suit dans l'assemblage "JAL X1, PRAM_RESETVector" et est situé à l'adresse 0x000085E8. Le codage d'instructions (RISC32) semble comme suit 0xeff09FA9.
Cependant, que se passe-t-il après avoir exécuté l'instruction de saut, c'est que je termine à l'adresse 0x00008082 au lieu du 0x00008080 prévu.
Je ne peux pas sembler trouver la raison de cela, que quelqu'un pourrait vous aider ici?
3 Réponses :
L'instruction est "0xeff09FA9"? Ces 32 bits sont en fait deux instructions de deux octets différents, C.SD et C.ADDW.
0xa99ff0ef 10101001100111111111000011101111 imm[20|10:1|11|19:12, rd, 110111 1 0101001100 1 11111111 00001 1101111 1 11111111 1 0101001100 111111111 1010 1001 1000 0xFFFFFA98 + 0x000085e8 = 0x8080
Je ne suis pas suivi, que voulez-vous dire avec 'Les outils GNU sont débogués "? Comment arrive-tu de 0xeff09FA9 à 0xA99FF0EF ?
J'ai essayé ce qui suit dans les rars et cela a fonctionné comme on peut s'y attendre.
Je devais déplacer la section de texte dans la plage valide pour les rarres, mais sinon
a99ff0ef
Quel processeur utilisez-vous? Est-ce auto-développé? Avec quels outils générez-vous vos programmes? Encore une fois, des outils auto-développés ou des fonctionnaires de la Fondation RISC-V? Si vous utilisez un processeur auto-développé, mais les outils des officiels, votre bogue réside dans votre processeur.
C'est le point zéro comme trouvé sur github ( github.com/pulp-platform/zero-riscy < / a>) sans personnalisations dans la logique RISCV. Les outils de développement de GCC sont utilisés (RISCV-NON-Aucun-GCC).