Formato ejecutable y enlazable

format_list_bulleted Contenido keyboard_arrow_down

ImprimirCitar

Un archivo ELF tiene dos vistas: el encabezado del programa muestra el segmentos utilizado en el tiempo de ejecución, mientras que el encabezado de la sección enumera el conjunto de secciones.

En informática, el formato ejecutable y enlazable (ELF, antes denominado formato de enlace extensible), es un formato de archivo estándar común para archivos ejecutables archivos, código objeto, bibliotecas compartidas y volcados de núcleo. Publicado por primera vez en la especificación para la interfaz binaria de aplicaciones (ABI) de la versión del sistema operativo Unix denominada System V Release 4 (SVR4), y luego en Tool Interface Standard, fue rápidamente aceptado entre diferentes proveedores de sistemas Unix. En 1999, el proyecto 86open lo eligió como el formato de archivo binario estándar para Unix y sistemas similares a Unix en procesadores x86.

Por diseño, el formato ELF es flexible, extensible y multiplataforma. Por ejemplo, admite diferentes endianness y tamaños de dirección, por lo que no excluye ninguna unidad central de procesamiento (CPU) o arquitectura de conjunto de instrucciones en particular. Esto ha permitido que muchos sistemas operativos diferentes lo adopten en muchas plataformas de hardware diferentes.

Diseño de archivo

Cada archivo ELF se compone de un encabezado ELF, seguido de los datos del archivo. Los datos pueden incluir:

Mesa de encabezado del programa, que describe cero o más segmentos de memoria
Tabla de encabezados de la sección, describiendo cero o más secciones
Datos a que se refieren las entradas en la tabla de encabezado del programa o tabla de encabezados de sección

Estructura de un archivo ELF con entradas clave destacadas

Los segmentos contienen información necesaria para la ejecución del archivo en tiempo de ejecución, mientras que las secciones contienen datos importantes para la vinculación y la reubicación. Cualquier byte en el archivo completo puede ser propiedad de una sección como máximo, y pueden ocurrir bytes huérfanos que no sean propiedad de ninguna sección.

00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 3e 00 01 00 00 00 c5 48 40 00 00 00 00 00 |..>......H@.....|

Ejemplo de hexdump del encabezado del archivo ELF

Encabezado del archivo

El encabezado ELF define si usar direcciones de 32 bits o de 64 bits. El encabezado contiene tres campos que se ven afectados por esta configuración y compensan otros campos que los siguen. El encabezado ELF tiene una longitud de 52 o 64 bytes para binarios de 32 y 64 bits, respectivamente.

Offset Tamaño (bytes) Campo Propósito

32-bit 64-bit 32-bit 64-bit

0x00 4 e_ident[EI_MAG0] a través de e_ident[EI_MAG3] 0x7F seguido ELF()45 4c 46) en ASCII; estos cuatro bytes constituyen el número mágico.

0x04 1 e_ident[EI_CLASS] Este byte está listo para cualquiera 1 o 2 para significar formato 32- o 64-bit, respectivamente.

0x05 1 e_ident[EI_DATA] Este byte está listo para cualquiera 1 o 2 para significar poco o grande endianness, respectivamente. Esto afecta a la interpretación de campos de varios bytes empezando por offset 0x10.

0x06 1 e_ident[EI_VERSION] Set to 1 para la versión original y actual de ELF.

0x07

e_ident[EI_OSABI]

Identifica el sistema operativo objetivo ABI.

Valor	ABI
0x00	Sistema V
0x01	HP-UX
0x02	NetBSD
0x03	Linux
0x04	GNU Hurd
0x06	Solaris
0x07	AIX (Monterey)
0x08	IRIX
0x09	FreeBSD
0x0A	Tru64
0x0B	Novell Modesto
0x0C	OpenBSD
0x0D	OpenVMS
0x0E	Borde sin parar
0x0F	AROS
0x10	FenixOS
0x11	Nuxi CloudABI
0x12	Stratus Technologies OpenVOS

0x08

e_ident[EI_ABIVERSION]

Especifica además la versión ABI. Su interpretación depende del objetivo ABI. Linux kernel (después de al menos 2.6) no tiene definición de ello, por lo que se ignora para los ejecutables vinculados estadísticamente. En ese caso, el offset y el tamaño de EI_PAD son 8.

glibc 2.12+ en caso e_ident[EI_OSABI] == 3 trata este campo como versión ABI del linker dinámico: define una lista de características dinámicas del linker, trata e_ident[EI_ABIVERSION] como un nivel de características solicitado por el objeto compartido (librería ejecutable o dinámica) y se niega a cargarlo si se solicita una característica desconocida, es decir. e_ident[EI_ABIVERSION] es mayor que la mayor característica conocida.

0x09 7 e_ident[EI_PAD] Bytes de padding reservados. Actualmente no utilizado. Debe llenarse de ceros e ignorarse cuando se lee.

0x10

e_type

Identifica el tipo de archivo objeto.

Valor	Tipo	Significado
0x00	ET_NONE	Desconocido.
0x01	ET_REL	Relocatable file.
0x02	ET_EXEC	Archivo ejecutable.
0x03	ET_DYN	Objeto compartido.
0x04	ET_CORE	Archivo básico.
0xFE00	ET_LOOS	Rango incluido reservado. Sistema operativo específico.
0xFEFF	ET_HIOS	Rango incluido reservado. Sistema operativo específico.
0xFF00	ET_LOPROC	Rango incluido reservado. Procesador específico.
0xFF	ET_HIPROC	Rango incluido reservado. Procesador específico.

0x12

e_machine

Especifica la arquitectura del conjunto de instrucciones objetivo. Algunos ejemplos son:

Valor	ISA
0x00	No se ha establecido ninguna instrucción específica
0x01	EN VIRTUD DE LOS 32100
0x02	SPARC
0x03	x86
0x04	Motorola 68000 (M68k)
0x05	Motorola 88000 (M88k)
0x06	Intel MCU
0x07	Intel 80860
0x08	MIPS
0x09	IBM System/370
0x0A	MIPS RS3000 Little-endian
0x0B - 0x0D	Reservado para uso futuro
0x0E	Hewlett-Packard PA-RISC
0x0F	Reservado para uso futuro
0x13	Intel 80960
0x14	PowerPC
0x15	PowerPC (64 bits)
0x16	S390, incluido S390x
0x17	IBM SPU/SPC
0x18 - 0x23	Reservado para uso futuro
0x24	NEC V800
0x25	Fujitsu FR20
0x26	TRW RH-32
0x27	Motorola RCE
0x28	Arm (hasta Armv7/AArch32)
0x29	Digital Alpha
0x2A	SuperH
0x2B	SPARC Version 9
0x2C	Procesador integrado Siemens TriCore
0x2D	Argonaut RISC Core
0x2E	Hitachi H8/300
0x2F	Hitachi H8/300 H
0x30	Hitachi H8S
0x31	Hitachi H8/500
0x32	IA-64
0x33	Stanford MIPS-X
0x34	Motorola ColdFire
0x35	Motorola M68HC12
0x36	Fujitsu MMA Multimedia Accelerator
0x37	Siemens PCP
0x38	Sony nCPU integrado procesador RISC
0x39	Denso NDR1 microprocesador
0x3A	Motorola Star*Procesador de coches
0x3B	Procesador Toyota ME16
0x3C	STMicroelectronics ST100 processor
0x3D	Advanced Logic Corp. Tiny J embebido procesador familia
0x3E	AMD x86-64
0x3F	Sony DSP Procesador
0x40	Digital Equipment Corp. PDP-10
0x41	Digital Equipment Corp. PDP-11
0x42	Siemens FX66 microcontrolador
0x43	STMicroelectronics ST9+ 8/16 bit microcontroller
0x44	STMicroelectronics ST7 8-bit microcontroller
0x45	Microcontrolador Motorola MC68HC16
0x46	Microcontrolador Motorola MC68HC11
0x47	Microcontrolador Motorola MC68HC08
0x48	Microcontrolador Motorola MC68HC05
0x49	Gráficos de silicona SVx
0x4A	STMicroelectronics ST19 8-bit microcontroller
0x4B	VAX digital
0x4C	Axis Communications Procesador integrado de 32 bits
0x4D	Infineon Technologies procesador integrado de 32 bits
0x4E	Element 14 64-bit DSP Procesador
0x4F	LSI Logic 16-bit DSP Processor
0x8C	TMS320C6000 Familia
0xAF	MCST Elbrus e2k
0xB7	Arm 64-bits (Armv8/AArch64)
0xDC	Zilog Z80
0xF3	RISC-V
0xF7	Filtro de paquete de Berkeley
0x101	WDC 65C816

0x14 4 e_version Set to 1 para la versión original de ELF.

0x18 4 8 e_entrada Esta es la dirección de memoria del punto de entrada desde donde el proceso comienza a ejecutar. Este campo es de 32 o 64 bits de largo, dependiendo del formato definido anteriormente (byte 0x04). Si el archivo no tiene un punto de entrada asociado, entonces esto tiene cero.

0x1C 0x20 4 8 e_phoff Puntos al inicio de la mesa de encabezado del programa. Por lo general sigue el encabezado del archivo inmediatamente después de éste, haciendo el offset 0x34 o 0x40 para los ejecutables ELF de 32 y 64 bits, respectivamente.

0x20 0x28 4 8 e_shoff Puntos al inicio de la tabla de encabezados de sección.

0x24 0x30 4 e_flags La interpretación de este campo depende de la arquitectura de destino.

0x28 0x34 2 e_ehsize Contiene el tamaño de este encabezado, normalmente 64 Bytes para 64-bit y 52 Bytes para formato 32-bit.

0x2A 0x36 2 e_phentsize Contiene el tamaño de una tabla de encabezado del programa.

0x2C 0x38 2 e_phnum Contiene el número de entradas en la tabla de encabezados del programa.

0x2E 0x3A 2 e_shentsize Contiene el tamaño de una tabla de cabecera de sección.

0x30 0x3C 2 e_shnum Contiene el número de entradas en la tabla de encabezados de la sección.

0x32 0x3E 2 e_shstrndx Contiene índice de la entrada de la tabla de encabezado de sección que contiene los nombres de las secciones.

0x34 0x40 Fin de la cabecera ELF (tamaño).

Encabezado del programa

La tabla de encabezado del programa le dice al sistema cómo crear una imagen de proceso. Se encuentra en el desplazamiento del archivo e_phoff y consta de entradas e_phnum, cada una con tamaño e_phentsize . El diseño es ligeramente diferente en ELF de 32 bits frente a ELF de 64 bits, porque las p_flags están en una ubicación de estructura diferente por motivos de alineación. Cada entrada está estructurada como:

Offset Tamaño (bytes) Campo Propósito

32-bit 64-bit 32-bit 64-bit

0x00

p_type

Identifica el tipo del segmento.

Valor	Nombre	Significado
0x00000	PT_NULL	Ingreso de mesa de encabezado del programa no utilizado.
0x00001	PT_LOAD	segmento Loadable.
0x00000002	PT_DYNAMIC	Información de conexión dinámica.
0x00000003	PT_INTERP	Información del intérprete.
0x00004	PT_NOTE	Información auxiliar.
0x00005	PT_SHLIB	Reservado.
0x00006	PT_PHDR	Segmento que contiene la tabla de encabezado del programa en sí.
0x00007	PT_TLS	Thread-Local Plantilla de almacenamiento.
0x60000000	PT_LOOS	Rango incluido reservado. Sistema operativo específico.
0x6FFFF	PT_HIOS	Rango incluido reservado. Sistema operativo específico.
0x70000000	PT_LOPROC	Rango incluido reservado. Procesador específico.
0x7FFFFF	PT_HIPROC	Rango incluido reservado. Procesador específico.

0x04 4 p_flags Banderas dependientes del segmento (posición para la estructura de 64 bits).

0x04 0x08 4 8 p_offset Offset del segmento en la imagen del archivo.

0x08 0x10 4 8 p_vaddr Dirección virtual del segmento en memoria.

0x0C 0x18 4 8 P_paddr En sistemas donde la dirección física es relevante, reservada para la dirección física del segmento.

0x10 0x20 4 8 p_filesz Tamaño en bytes del segmento en la imagen del archivo. Puede ser 0.

0x14 0x28 4 8 p_memsz Tamaño en bytes del segmento en memoria. Puede ser 0.

0x18 4 p_flags Banderas dependientes del segmento (posición para estructura de 32 bits).

0x1C 0x30 4 8 p_align 0 y 1 especificar no alineación. De lo contrario debe ser un poder positivo e integral de 2, con p_vaddr equiparación p_offset modulus p_align.

0x20 0x38 Fin del programa Header (tamaño).

Encabezado de sección

Offset

Tamaño (bytes)

Campo

Propósito

32-bit

64-bit

32-bit

64-bit

0x00

sh_name

Un offset a una cadena en el .shstrtab sección que representa el nombre de esta sección.

0x04

sh_type

Identifica el tipo de este encabezado.

Valor	Nombre	Significado
0x0	SHT_NULL	Sección de cabecera de la mesa
0x1	SHT_PROGBITS	Datos del programa
0x2	SHT_SYMTAB	Signatura
0x3	SHT_STRTAB	Mesa de montaje
0x4	SHT_RELA	Entradas de reubicación con adiciones
0x5	SHT_HASH	Signatura de la tabla
0x6	SHT_DYNAMIC	Información dinámica de enlace
0x7	SHT_NOTE	Notas
0x8	SHT_NOBITS	Espacio del programa sin datos (bss)
0x9	SHT_REL	Entradas de traslado, sin adiciones
0x0A	SHT_SHLIB	Reservado
0x0B	SHT_DYNSYM	Tabla de símbolo de enlace dinámico
0x0E	SHT_INIT_ARRAY	Array de constructores
0x0F	SHT_FINI_ARRAY	Array of destructors
0x10	SHT_PREINIT_ARRAY	Array of pre-constructors
0x11	SHT_GROUP	Grupo de sección
0x12	SHT_SYMTAB_SHNDX	Índices de sección ampliados
0x13	SHT_NUM	Número de tipos definidos.
0x60000000	SHT_LOOS	Comience el sistema operativo específico.
...	...	...

0x08

sh_flags

Identifica los atributos de la sección.

Valor	Nombre	Significado
0x1	SHF_WRITE	Writable
0x2	SHF_ALLOC	Ocupa la memoria durante la ejecución
0x4	SHF_EXECINSTR	Ejecución
0x10	SHF_MERGE	Podría ser fusionado.
0x20	SHF_STRINGS	Contiene cuerdas nula-terminadas
0x40	SHF_INFO_LINK	'sh_info' contiene índice SHT
0x80	SHF_LINK_ORDER	Orden Preserve después de combinar
0x100	SHF_OS_NONCONFORMING	Manejo específico no estándar del sistema operativo requerido
0x200	SHF_GROUP	Sección es miembro de un grupo
0x400	SHF_TLS	Sección mantiene datos locales de rosca
0x0FF00000	SHF_MASKOS	OS-specific
0xF0000000	SHF_MASKPROC	Procesador específico
0x4000000	SHF_ORDERED	Requisitos especiales de orden (Solaris)
0x8000000	SHF_EXCLUDE	La sección queda excluida a menos que se haga referencia o se asigne (Solaris)

0x0C

0x10

sh_addr

Dirección virtual de la sección en memoria, para secciones cargadas.

0x10

0x18

sh_offset

Offset de la sección en la imagen del archivo.

0x14

0x20

sh_size

Tamaño en bytes de la sección en la imagen del archivo. Puede ser 0.

0x18

0x28

sh_link

Contiene el índice de sección de una sección asociada. Este campo se utiliza para varios fines, dependiendo del tipo de sección.

0x1C

0x2C

sh_info

Contiene información adicional sobre la sección. Este campo se utiliza para varios fines, dependiendo del tipo de sección.

0x20

0x30

sh_addralign

Contiene la alineación necesaria de la sección. Este campo debe ser un poder de dos.

0x24

0x38

sh_entsize

Contiene el tamaño, en bytes, de cada entrada, para secciones que contienen entradas de tamaño fijo. De lo contrario, este campo contiene cero.

0x28

0x40

End of Section Header (size).

Herramientas

readelf es una utilidad binaria Unix que muestra información sobre uno o más archivos ELF. GNU Binutils proporciona una implementación de software libre.
elfutils proporciona herramientas alternativas a GNU Binutils puramente para Linux.
elfdump es un comando para ver la información ELF en un archivo ELF, disponible bajo Solaris y FreeBSD.
objdump proporciona una amplia gama de información sobre archivos ELF y otros formatos de objetos. objdump utiliza la biblioteca descriptor de archivos binario como back-end para estructurar los datos ELF.
El Unix file la utilidad puede mostrar cierta información sobre los archivos ELF, incluyendo la arquitectura del conjunto de instrucciones para la cual se pretende el código en un archivo de objeto relocatable, ejecutable o compartido, o en el que se produjo un basurero ELF.

Aplicaciones

Sistemas similares a Unix

El formato ELF ha reemplazado a los formatos ejecutables más antiguos en varios entornos. Ha reemplazado los formatos a.out y COFF en sistemas operativos similares a Unix:

Linux
Solaris / Illumos
IRIX
FreeBSD
NetBSD
OpenBSD
Redox
DragonFly BSD
Syllable
HP-UX (excepto los programas PA-RISC de 32 bits que siguen utilizando SOM)
QNX Neutrino
MINIX

Adopción no Unix

ELF también ha visto cierta adopción en sistemas operativos que no son de Unix, como:

OpenVMS, en sus versiones Itanium y amd64
BeOS Revision 4 y posterior para ordenadores basados en x86 (donde sustituyó el formato ejecutable portátil; la versión PowerPC se mantuvo con Formato ejecutable Preferente)
Haiku, una reimplementación de código abierto de BeOS
RISC OS
Stratus VOS, en las versiones PA-RISC y x86
SkyOS
Fuchsia OS
Z/TPF
HPE NonStop OS
Deos

Microsoft Windows también usa el formato ELF, pero solo para su subsistema de Windows para el sistema de compatibilidad con Linux.

Consolas de juegos

Algunas videoconsolas también usan ELF:

PlayStation Portable, PlayStation Vita, PlayStation (consol), PlayStation 2, PlayStation 3, PlayStation 4, PlayStation 5
GP2X
Dreamcast
GameCube
Nintendo 64
Wii
Wii U

PowerPC

Otros sistemas (operativos) que se ejecutan en PowerPC que utilizan ELF:

AmigaOS 4, el ejecutable ELF ha reemplazado el anterior formato Extended Hunk (EHF) que se utilizó en Amigas equipado con tarjetas de expansión de procesador PPC.
MorphOS
AROS
Café OS (El sistema operativo funcionó en Wii U)

Teléfonos móviles

Algunos sistemas operativos para teléfonos móviles y dispositivos móviles utilizan ELF:

Symbian OS v9 utiliza E32 Formato de imagen que se basa en el formato de archivo ELF;
Sony Ericsson, por ejemplo, el W800i, W610, W300, etc.
Siemens, las plataformas SGOLD y SGOLD2: de Siemens C65 a S75 y BenQ-Siemens E71/EL71;
Motorola, por ejemplo, el E398, SLVR L7, v360, v3i (y todo el teléfono LTE2 que tiene el parche aplicado).
Bada, por ejemplo, el Samsung Wave S8500.
Nokia teléfonos o tabletas que ejecutan el Maemo o el Meego OS, por ejemplo, el Nokia N900.
Android utiliza ELF .so (objeto compartido) bibliotecas para la Interfaz Nativa Java. Con Android Runtime (ART), el predeterminado desde Android 5.0 "Lollipop", todas las aplicaciones se compilan en binarios ELF nativos en la instalación.

Algunos teléfonos pueden ejecutar archivos ELF mediante el uso de un parche que agrega código ensamblador al firmware principal, que es una característica conocida como ELFPack en la cultura de modificación clandestina. El formato de archivo ELF también se usa con Atmel AVR (8 bits), AVR32 y con arquitecturas de microcontrolador Texas Instruments MSP430. Algunas implementaciones de Open Firmware también pueden cargar archivos ELF, sobre todo la implementación de Apple utilizada en casi todas las máquinas PowerPC que produjo la empresa.

Especificaciones

Genérico:
- Aplicación del sistema V Interfaz binaria Edición 4.1 (1997-03-18)
- Actualización del sistema V ABI (octubre de 2009)
AMD64:
- Sistema V ABI, Suplemento AMD64
Arm:
- ELF para la arquitectura ARM
IA-32:
- Sistema V ABI, Intel386 Suplemento Procesador de Arquitectura
IA-64:
- Convenciones de software de itanio y guía de tiempo de ejecución (septiembre de 2000)
M32R:
- M32R ELF ABI Suplemento Versión 1.2 (2004-08-26)
MIPS:
- System V ABI, MIPS RISC Processor Supplement
- MIPS EABI documentation (2003-06-11)
Motorola 6800:
- Motorola 8 y 16 bits ABI
PA-RISC:
- ELF Supplement for PA-RISC Versión 1.43 (6 de octubre de 1997)
PowerPC:
- Sistema V ABI, Suplemento PPC
- PowerPC Aplicación incorporada Interfaz binaria 32-Bit Implementación (1995-10-01)
- 64-bit PowerPC ELF Aplicación Suplemento de interfaz binaria Versión 1.9 (2004)
RISC-V:
- RISC-V ELF Especificación
SPARC:
- Sistema V ABI, SPARC Suplemento
S/390:
- S/390 32bit ELF ABI Suplemento
zSeries:
- zSeries 64bit ELF ABI Suplemento
Symbian OS 9:
- E32Image formato de archivo en Symbian OS 9

Linux Standard Base (LSB) complementa algunas de las especificaciones anteriores para las arquitecturas en las que se especifica. Por ejemplo, ese es el caso de System V ABI, AMD64 Supplement.

86abierto

86open fue un proyecto para llegar a un consenso sobre un formato de archivo binario común para Unix y sistemas operativos similares a Unix en la arquitectura común x86 compatible con PC, para alentar a los desarrolladores de software a migrar a la arquitectura. La idea inicial era estandarizar un pequeño subconjunto de Spec 1170, un predecesor de Single UNIX Specification, y GNU C Library (glibc) para permitir que los archivos binarios no modificados se ejecutaran en los sistemas operativos x86 similares a Unix. El proyecto se designó originalmente como "Spec 150".

El formato finalmente elegido fue ELF, específicamente la implementación de ELF en Linux, después de que resultó ser un estándar de facto compatible con todos los proveedores y sistemas operativos involucrados.

El grupo comenzó conversaciones por correo electrónico en 1997 y se reunió por primera vez en las oficinas de la Operación Santa Cruz el 22 de agosto de 1997.

El comité directivo estaba formado por Marc Ewing, Dion Johnson, Evan Leibovitch, Bruce Perens, Andrew Roach, Bryan Wayne Sparks y Linus Torvalds. Otras personas en el proyecto fueron Keith Bostic, Chuck Cranor, Michael Davidson, Chris G. Demetriou, Ulrich Drepper, Don Dugger, Steve Ginzburg, Jon "maddog" Hall, Ron Holt, Jordan Hubbard, Dave Jensen, Kean Johnston, Andrew Josey, Robert Lipe, Bela Lubkin, Tim Marsland, Greg Page, Ronald Joe Record, Tim Ruckle, Joel Silverstein, Chia-pi Tien y Erik Troan. Los sistemas operativos y las empresas representadas fueron BeOS, BSDI, FreeBSD, Intel, Linux, NetBSD, SCO y SunSoft.

El proyecto avanzó y, a mediados de 1998, SCO comenzó a desarrollar lxrun, una capa de compatibilidad de código abierto capaz de ejecutar binarios de Linux en OpenServer, UnixWare y Solaris. SCO anunció el soporte oficial de lxrun en LinuxWorld en marzo de 1999. Sun Microsystems comenzó a admitir oficialmente lxrun para Solaris a principios de 1999 y luego pasó al soporte integrado del formato binario de Linux a través de Solaris Containers for Linux Applications.

Dado que los BSD admitieron durante mucho tiempo los binarios de Linux (a través de una capa de compatibilidad) y los principales proveedores de Unix x86 agregaron soporte para el formato, el proyecto decidió que Linux ELF era el formato elegido por la industria y "declaró[ d] sí mismo disuelto" el 25 de julio de 1999.

FatELF: binarios universales para Linux

FatELF es una extensión de formato binario ELF que agrega capacidades binarias gruesas. Está dirigido a Linux y otros sistemas operativos similares a Unix. Además de la abstracción de la arquitectura de la CPU (orden de bytes, tamaño de palabra, conjunto de instrucciones de la CPU, etc.), existe la ventaja potencial de la abstracción de la plataforma de software, por ejemplo, binarios que admiten múltiples versiones ABI del kernel. A partir de 2021, FatELF no se ha integrado en el núcleo principal de Linux.

Contenido relacionado

Más resultados...