ar.h 32-bits & mmap alignement
Bonjour a tous.
Je rencontre actuellement un probleme en travaillant avec le standard des archives sous Unix.
En effet, dans le but de travailler sur ces fichiers (.a), j'utilise le header situe a /usr/include/ar.h que voici :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| ifndef _AR_H
#define _AR_H 1
#include <sys/cdefs.h>
/* Archive files start with the ARMAG identifying string. Then follows a
`struct ar_hdr', and as many bytes of member file data as its `ar_size'
member indicates, for each member file. */
#define ARMAG "!<arch>\n" /* String that begins an archive file. */
#define SARMAG 8 /* Size of that string. */
#define ARFMAG "`\n" /* String in ar_fmag at end of each header. */
__BEGIN_DECLS
struct ar_hdr
{
char ar_name[16]; /* Member file name, sometimes / terminated. */
char ar_date[12]; /* File date, decimal seconds since Epoch. */
char ar_uid[6], ar_gid[6]; /* User and group IDs, in ASCII decimal. */
char ar_mode[8]; /* File mode, in ASCII octal. */
char ar_size[10]; /* File size, in ASCII decimal. */
char ar_fmag[2]; /* Always contains ARFMAG. */
};
__END_DECLS
#endif /* ar.h */ |
Grace a ce header, j'arrive parfaitement a decoder les differents membres de l'archive, qui, je le precise, sont des donnees de type ELF RELOCATABLE (communement des objets ou .o) en 64-bits.
En revanche, des que je travaille sur une librarie statique qui contient des objets 32-bits, toutes mes routines de parsing sont alors fausses.
Je suis tombe sur cet excellent article d'un employe de Sun : http://blogs.oracle.com/ali/entry/64...rchives_needed
et il explique deux trois choses a propos de l'alignement interne des objets. Le probleme c'est que je ne saisis pas du tout ces notions de padding ou de "bounded pointer", n'ayant pas une experience grande dans ce domaine... (je commence depuis peu la programmation avancee de ce type).
Ainsi, si quelqu'un pouvait decoder ce paragraphe, et me l'expliquer, cela m'aiderait beaucoup :
Citation:
The requirement to pad members to an even length is a dead giveaway as to the age of the archive format. It tells you that this format dates from the 1970's, and more specifically from the era of 16-bit systems such as the PDP-11 that Unix was originally developed on. A 32-bit system would have required 4 bytes, and 64-bit systems such as we use today would probably have required 8 bytes. 2 byte alignment is a poor choice for ELF object archive members. 32-bit objects require 4 byte alignment, and 64-bit objects require 64-bit alignment. The link-editor uses mmap() to process archives, and if the members have the wrong alignment, we have to slide (copy) them to the correct alignment before we can access the ELF data structures inside. The archive format requires 2 byte padding, but it doesn't prohibit more. The Solaris ar command takes advantage of this, and pads ELF object members to 8 byte boundaries. Anything else is padded to 2 as required by the format.
Je precise que j'utilise mmap afin de mapper l'ensemble de mon fichier en memoire. Je travaille alors sur cette plage de donnees.
Merci d'avance, et si besoin est, n'hesitez a me demander plus details, en esperant avoir ete clair.
William
