Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

GHDL (gcc/llvm): the executable is relinked for every test

Abierto
  • ¿Algo no está bien?
#1,233 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Área
testing

Línea de trabajo

Read the GHDL backend code that invokes ghdl --elab-run and compare it with the linked fork commit. Trace how elaboration flags, simulation arguments, configurations, and coverage settings are passed for gcc and llvm backends. Done means executable reuse works for matching elaborations, while the listed exclusions and failure behavior are covered by tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

With the gcc and llvm backends, GHDL writes an executable at elaboration. VUnit runs every test with ghdl --elab-run, so that executable is linked again for each test, although it only depends on the design and on the elaboration flags (the generics and the test to run are passed to it when it starts).

I looked through the repository and issue history to check whether this is intended, and found nothing saying so (--elab-run has been the only GHDL command since GHDL support was added).

For small test benches with many tests or many configurations, the linking may take longer than the simulations themselves. Linking the executable once per run and starting it directly for every test that elaborates the same design with the same elaboration flags would significantly increase performance in such cases.

I have implemented this on a branch of my fork: https://github.com/VUnit/vunit/commit/6983b0af73c52b29b3b44fcf83d3958f4013ce73
I'm not familiar enough with the codebase to be comfortable submitting it as a pull request, as it introduces some behavior changes.

The idea is:

  • The executable is linked with ghdl -e into <output path>/executables/<hash of the elaboration arguments>/<entity>-<architecture> by the first test that needs it. The other tests of the same design wait for it and then run it with their own simulation arguments (-g generics, ghdl.sim_flags, wave file, --no-run for --elaborate).
  • Tests with different ghdl.elab_flags, a different VHDL configuration or different coverage settings get their own executable.
  • If linking fails, the first test shows the linker output, and the other tests of that design fail without linking again.

This does not apply to the mcode and llvm-jit backends, --elaborate with ghdl.elab_e, and coverage with the llvm backend, where the coverage output file is an elaboration argument.

Side effects/Behavior changes in my implementation:

  • The executable is no longer in the output path of each test (<test output>/ghdl/<entity>-<architecture>).
  • ghdl.elab_flags are passed to ghdl -e and ghdl.sim_flags to the executable, instead of both to ghdl --elab-run.
  • Directories under <output path>/executables from earlier runs with other flags are not removed.
Lenguaje dominante
VHDL
Estrellas
850
Forks
305
Merge medio
2 d 10 h
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de VUnit/vunit

Todos los issues de VUnit/vunit

Issues similares

Más issues de Testing & QA

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.