Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,233 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Ambito
testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
VHDL
Stelle
850
Fork
305
Merge medio
2g 10h
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di VUnit/vunit

Tutte le issue di VUnit/vunit

Issue simili

Altre issue su Testing & QA

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.