relogements kernel - Page 1

Je suis en train de coder un désassembleur de programmes. J'ai presque fini de coder le désassemblage de fichiers kernels, mais il: manque une info : j'ai l'impression que les prog ont deux tables de relogements (de taille identique) qui sont situées après la RAM_Table. A quoi sert la 2ème ?

et autre question, tous les relogements se font bien sur des long (sauf certains RAM_CALL) ?

Pour la 2è question, c'est oui. Pour la 1è, ben j'ai pas la doc sous les yeux.

j'ai regardé dans la doc, en fait, je travaille avec la doc de PpHd sous les yeux et ça n'y est pas, c'est pour ça que je comprend pas. En tout cas, il ne me reste plus que ça à désassembler

Ben en fait a priori d'après les sources de GTC j'ai l'impression que juste après la RAM table y a les relocs.

Tout est dans les sources du linker.

[...]
__kernel_fixed_header_end:

| Kernel library import table.
.section _stl2, "d"
__kernel_lib_table:
__kernel_lib_count_pos:
	.word __ld_referenced_lib_count
__ld_insert_kernel_libs:
| The format for the library table is as follows:
| For each library...
|   8 bytes: name
|   1 byte: 0
|   1 byte: minimum version
| For each library...
|   2 bytes: function import count - 1
|   For each imported function...
|     2 bytes: function index in the library
|     For each reloc...
|       2 bytes: offset into the program
|     2 bytes: 0

| ROM call import table.
.section _stl3, "d"
__kernel_rom_call_table:
__kernel_has_rom_calls_pos:
	.word __ld_has_rom_calls
__ld_insert_kernel_rom_calls:
| The format for the ROM call table is as follows:
| 2 bytes: ROM call count - 1
| For each ROM call used...
|   2 bytes: ROM call number
|   For each reloc...
|     2 bytes: offset into the program
|   2 bytes: 0

| RAM call import table.
.section _stl4, "d"
__kernel_ram_call_table:
__kernel_has_ram_calls_pos:
	.word __ld_has_ram_calls
__ld_insert_kernel_ram_calls:
| The format for the RAM call table is as follows:
| 2 bytes: RAM call count - 1
| For each RAM call used...
|   2 bytes: RAM call number
|     Bit 14: extra RAM address
|     Bit 15: 2-byte references (instead of 4)
|   For each reloc...
|     2 bytes: offset into the program
|   2 bytes: 0

| Relocation table.
.section _stl5, "d"
__kernel_reloc_table:
__ld_insert_kernel_relocs:
| The format for the reloc table is as follows:
| For each reloc...
|   2 bytes: offset into the program
| 2 bytes: 0

Non, tout est dans les sources de GTC :

			...
			wri(rom);	// ROM table
			if (rom) write_functab(rom_funcs);
			wri(ram);	// RAM table
			if (ram) write_functab(ram_funcs);
			write_reloc();	// reloc table

étrange ... j'ai dû me planter alors.
Encore une question : comment on se sert des BSS (je connais pas la syntaxe) - j'ai complètement oublié de le faire. Sinon, je peux maintenant désassembler txtrider et le réassembler => il commence à bien tourner mon désassembleur

Dans a68k, tu fais une section BSS et des ds.b dedans.

Et si t'arrives à désassembler la ROM (enfin plutôt, si t'en as le courage), ça m'intéresse

Syntaxe:

| Kernel Program/Library BSS Table
| This belongs to the kernel headers.

	.xdef __kernel_bss_table,__ld_insert_kernel_bss_refs
.section _stl13, "d"

__kernel_bss_table:
__kernel_bss_size_pos:
	.long __ld_bss_size
__ld_insert_kernel_bss_refs:
| The format for the BSS table is as follows:
| For each reloc...
|   2 bytes: offset into the program
| 2 bytes: 0

Ce que ça fait: c'est une partie du programme de taille __ld_bss_size allouée automatiquement par le kernel. Les targets des relogements sont relatifs au début de la section BSS.

bah en fait, c'est sur la liste. Je pense que le désassemblage de ROM est plus simple en théorie que le désassemblage de programmes kernel (y a pas bcp de relogements ). Ce qui est dur, ce de stocker toutes les données en RAM (il est on-calc le désassembleur), vu qu'en fait je fait 2 passages, pour pouvoir distinguer un minimum les données du code et aussi noter tous les endroits où il y a besoin d'un label. Pour les sources, il va y avoir une option envoyer les fichiers, comme ça on pourra faire tourner sous VTI et stocker les fichiers sur pc.

Tu fais ça on-calc?
Ca marche aussi on-PC, ou pas? Parce que c bien pratique de pouvoir faire tourner ce genre de prog sur PC... Et crois-moi, c 100x plus facile à débugger sur PC que on-calc (sinon, GTC n'en serait pas du tout là où il en est maintenant...)

euh... c'est-à-dire qu'il est en 68000, donc c'est aps franchement portable ...mais oui, je code sur pc (les routines essentielles du programmes ont été faites on-calc, mais au bout d'un moment ça voulait plus assembler, alors j'ai tout mis sur pc)

Tu le fais en ASM pur?

Mais t'es fou

rassure-toi, y a pas qu'un désassembleur : pour une source de 748ko, t'as un éditeur hexa (couplé à un désassembleur à la volée et à un machin pour voir la mémoire directement), un viewer de texte, un gestionnaire de TSR, tu peux effacer les apps flash ou avoir plein d'infos dessus,... et accessoirement t'as tout un shell avec plein de fonctions....

748 ko de source ça fait bcp... Combien compilé?

Enfin perso si je devais faire un désassembleur je le ferais en C (quitte à faire ce qui va autour en ASM).

pour l'instant, 49663o. Mais y a vraiment bcp de fonctions

Argl. Tout ces kilo-octets qui profiteront pas de GTC 2, ça me fait mal au coeur

En fait, le désassembleur, ça se fait très bien en ASM (c'est vrai que je viens de débuter le C). Et y a plein de trucs dont je ne suis aps sûr qu'on puisse les faire en C (surtout que je n'ai pas le droit aux relogements)

c'est vrai que je viens de débuter le C

Ah OK, c'est compréhensible. A l'époque de GTools je pensais tout faire en ASM

surtout que je n'ai pas le droit aux relogements

Il exécute son shell directement en ROM.

mon programme a 2 particularités pour économiser de la RAM :
sur 92+ il s'exécute tranquillement en archive
sur les autres, il s'exécute en RAM, mais quand il lance un autre programme, il peut s'effacer de la mémoire et se recréer à partir de la copie archivée au retour, alors c'est un peu le bordel pour bien gérer les adresses et je préfère tout faire moi -même (j'utilise une seconde pile)

Pour l'exécution en ROM, c'est pas un prétexte. Pour l'exécution en RAM, à la limite le code de relancement doit être fait en ASM, mais ce n'est pas du tout indispensable que le reste soit en ASM, non? Qu'est-ce qui pose problème?

comment on fait un relogement en ROM, sachant que le même programme doit s'exécuter indiféremment en RAM et en ROM ?
pour l'exécution en RAM, j'ai fait un truc moche : à chaque appel de sous-fonction susceptible d'être sur la pile alors que le shell est effacé, je remplace le code "bsr sub_func" par un "bsr push_address : bra sub_func". Le retour se fait par un "bsr pop_address" et non un "rts". Ca un peu été fait à l'arrache, mais ça marche .

Ce genre de chose peut toujours se faire à partir du code ASM généré par le compilo (petit patch...)

T'es sur que ca marche sous 92+ HW1 ?

Kevin disait que JM avait dit que les 92+ HW1 n'avait pas toutes une ghost space de la flash.

Si mes souvenirs sont bons, la mienne n'en a pas (mais je devrais verifier avant de le dire).

je n'ai pas pu tester sur toutes les HW1. J'ai tester seulement sur 1 ou 2 et ça marchait. De toute façon, je vérifie que la mémoire est identique à $200000 et à $400000 avant de s'y mettre, donc ça devrait pas planter s'il y a pas de ghost