Différences des vars ASM - Page 1

Salut à tous,
Lorsque l'on utilise un explorateur comme PC Tools, les fichiers de type ASM dans le Var-link apparaisses de 3 types différents : EXE, ASM et LIB. Quelle est la différence entre ASM et EXE et comment le programme fait il pour les distinguer ?

Alors dans une librairies, y a généralement une chaine du genre "libraries are not executable". Donc tu regarde si y a cette chaine, et si elle y est, c que c une lib. Pour l'EXE et l'ASM, je peut pas te dire, par contre, j'av jamais remarqué au temps ou j'utilisait PCTOOLS.

EXE, ça serait pas les programmes en mode kernel
et ASM ceux qui ne sont pas kernel ?

Martial>A peut-être, c vrai que c plus pratique que de chercher une chaine^^

Lorsque l'on utilise un explorateur comme PC Tools, les fichiers de type ASM dans le Var-link apparaisses de 3 types différents : EXE, ASM et LIB. Quelle est la différence entre ASM et EXE et comment le programme fait il pour les distinguer ?

dans pctools, ASM c'est les programmes nostub, EXE les programmes kernel (c'est inversé dans tictex) et LIB les bibliothèques dynamiques des programmes kernel.
Pour les distinguer, c'est facile, vu que les programmes kernels ont une signature. Si tu regardes avec un éditeur hexa, à partir du 6ème octet (ou 4ème, je sais plus), il y a '68kP' écrit pour les programmes, et '68kL' pour les libs. Il y a également '68CA' pour les packs archives.

ça dépend si tu considère que le programme commence au 1er ou au 3ème octet

OK merci a tous c'est exactement ce dont j'avais besoin!!!

Flanker : qu'est ce que t'appelle les packs archives ?

les fichiers comme stdlib : c'est un gros fichier qui contient plusieurs sous-fichiers, dont un exécutable qui sera lancé quand tu lances le pack archive. Les sous-fichiers peuvent être compressés à l'intérieur, ils seront automatiquement décompressés à l'extraction. Dans stdlib, les sous-fichiers sont les lib classiques

Le format se trouve également dans tigcc.a:

| Kernel Program Header
| The format of this header is documented in ProgFormat.txt of the DoorsOS
| developer version.

	.xdef __kernel_program_header_AND_NOT___preos_headers,__kernel_entry_point,__kernel_fixed_header_end,__ld_insert_kernel_libs,__ld_insert_kernel_rom_calls,__ld_insert_kernel_ram_calls,__ld_insert_kernel_relocs,__bss_handle

| Fixed kernel program header.
.section _stl1, "d"
__kernel_program_header:
| This is the kernel program entry point.
__kernel_entry_point:
| This is not actually a real bsr: The kernel uses the return address, but
| clears it from the stack. So does the no-kernel detection.
	bsr.w __kernel_program_stub
__kernel_program_signature:
	.ascii "68kP"
__kernel_reloc_count_pos:
	.word 0
__kernel_comment_pos:
	.word _comment-__kernel_entry_point
__kernel_main_pos:
| This has to be called '_main' for compatibility with kernel programs.
| The TIGCC '_main' function therefore has to be called '__main'.
	.word _main-__kernel_entry_point
__kernel_exit_pos:
	.word _exit-__kernel_entry_point
__kernel_flags_pos:
	.byte __ld_file_version
	.byte __ld_kernel_flags
__kernel_bss_handle_pos:
__bss_handle:
	.word 0
__kernel_bss_table_pos:
	.word __ld_kernel_bss_table-__kernel_entry_point
__kernel_export_table_pos:
	.word __ld_kernel_export_table-__kernel_entry_point
__kernel_extra_pos:
	.word _extraram-__kernel_entry_point
__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

| Kernel Program Stub
| This belongs to the kernel headers.

	.xdef __kernel_program_stub,__no_kernel_msg
.section _stl11

| This is the kernel program stub starting point.
__kernel_program_stub:
| Test the data at 0x30, which is nonzero if a kernel has been
| installed.
	tst.w 0x30
| No kernel: Display failure message.
	jbeq .L__disp_no_kernel_msg
| We have a kernel. Move the location of the kernel launcher
| (stored in memory location 0x34) to %a0.
	move.l 0x34,%a0
| Call the kernel launcher.
	jmp (%a0)

| This routine is not a normal function: It returns from the entire program.
.L__disp_msg:
| Get the address of the jump table in %a0.
	move.l 0xC8,%a0
| Get the address of ST_helpMsg in %a0.
	move.l (%a0,0xE6*4),%a0  /* ST_helpMsg */
| Call ST_helpMsg.
	jsr (%a0)
| Clean up the stack.
| Remove the last return address as well
| (from the bsr.w at the beginning of the program).
	addq.w #8,%sp
| Return from the entire program.
	rts

| This routine displays the "Kernel required" message in the status line.
.L__disp_no_kernel_msg:
| This does two things:
| 1. Put the address of __no_kernel_msg on the stack.
| 2. Jump to .L__disp_msg.
| Note that it will not return normally, but remove even four more bytes from
| the stack.
	jbsr .L__disp_msg
__no_kernel_msg:
	.asciz "Kernel required"
	.even

| Kernel Library Header
| The format of this header is documented in ProgFormat.txt of the DoorsOS
| developer version.

	.xdef __kernel_library_header_AND_NOT___preos_headers,__kernel_entry_point,__kernel_fixed_header_end,__ld_insert_kernel_libs,__ld_insert_kernel_rom_calls,__ld_insert_kernel_ram_calls,__ld_insert_kernel_relocs,__bss_handle

| Fixed kernel program header.
.section _stl1, "d"
__kernel_library_header:
| This is the kernel program entry point.
__kernel_entry_point:
| This is not actually a real bsr: The library stub will clear the return
| address from the stack. This may also be a bra.w, but maybe some kernels
| rely on the bsr.w.
	bsr.w __kernel_library_stub
__kernel_library_signature:
	.ascii "68kL"
__kernel_reloc_count_pos:
	.word 0
__kernel_comment_pos:
	.word _comment-__kernel_entry_point
__kernel_main_pos:
	.word 0
__kernel_exit_pos:
	.word _exit-__kernel_entry_point
__kernel_flags_pos:
	.byte __ld_file_version
	.byte __ld_kernel_flags
__kernel_bss_handle_pos:
__bss_handle:
	.word 0
__kernel_bss_table_pos:
	.word __ld_kernel_bss_table-__kernel_entry_point
__kernel_export_table_pos:
	.word __ld_kernel_export_table-__kernel_entry_point
__kernel_extra_pos:
	.word _extraram-__kernel_entry_point
__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:
| 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:
| 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

| Kernel Library Stub
| This belongs to the kernel headers.

	.xdef __kernel_library_stub,__not_executable_msg
.section _stl12

| This is the kernel library stub starting point.
__kernel_library_stub:
| This does two things:
| 1. Put the address of __not_executable_msg on the stack.
| 2. Jump to .L__disp_msg.
| Note that it will not return normally, but remove even four more bytes from
| the stack.
	jbsr .L__disp_msg
__not_executable_msg:
	.asciz "Libraries are not executable"
	.even

| This routine is not a normal function: It returns from the entire program.
.L__disp_msg:
| Get the address of the jump table in %a0.
	move.l 0xC8,%a0
| Get the address of ST_helpMsg in %a0.
	move.l (%a0,0xE6*4),%a0  /* ST_helpMsg */
| Call ST_helpMsg.
	jsr (%a0)
| Clean up the stack.
| Remove the last return address as well
| (from the bsr.w at the beginning of the program).
	addq.w #8,%sp
| Return from the entire program.
	rts

euh on voulait juste savoir si la signature 68kP était au 4ème ou au 6ème octet (d'ailleurs ça n'apparaît même pas clairement dans ton post )

oué mais la doc de tigcc est plus grosse donc plus mieux (Kevin compense comme il peut)

Bah, un bsr.w fait 4 octets, il faut savoir compter.

Et dans le même style comment on identifie les DLL (Cf la doc d'einstein) ?

les dll n'ont pas le tag ASM mais le tag OTH (de mémoire)
donc à la fin du fichier, t'as la séquence suivante
$00,'D','L','L',$00,$F8 , (OTH_TAG = $F8)

D'accord, merci beaucoup Flanker !

de rien