Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
VNC server wayvnc pro Wayland kompozitory postavené nad wlroots - ne GNOME, KDE nebo Weston - byl vydán ve verzi 0.10.0. Vydána byla také verze 1.0.0 související knihovny neatvnc.
Bylo oznámeno vydání Fedora Linuxu 44. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »Originál tohoto článku pro lwn.net napsal Goldwyn Rodrigues.
Poke-a-hole (pahole) je nástroj pro analýzu objektových souborů, který hledá velikost datových struktur a díry způsobené zarovnáváním prvků na šířku slova CPU překladačem. Jako příklad vezměme následující strukturu:
struct sample {
char a[2];
long l;
int i;
void *p;
short s;
};
Sečtením velikosti jednotlivých prvků získáme očekávanou velikost této struktury:
2*1 (char) + 4 (long) + 4 (int) + 4 (ukazatel) + 2 (short) = 16 bytů
Překlad na 32bitové architektuře (ILP32 či Int-Long-Pointer 32 bitů) ukazuje, že velikost je ve skutečnosti 20 bytů. Překladač vkládá byty navíc, kterými zarovnává prvky na šířku slova CPU. V tomto případě jsou vloženy 2 byty za char a[2] a za short s. Překlad programu na 64bitovém stroji (LP64 či Long-Pointer 64 bitů) vede k tomu, že struktura zabírá 40 bytů. V tomto případě je za char a[2] vloženo šest bytů, čtyři byty za int i a šest bytů za short s. Pahole bylo vyvinuto k tomu, aby se zaměřilo na takovéto díry vytvořené překladačem kvůli zarovnávání. Aby bylo možné objektové soubory analyzovat, musí být zdrojový kód přeložen s ladícím příznakem „-g“. V jádře je to aktivováno pomocí CONFIG_DEBUG_INFO nebo „Kernel Hacking > Compile the kernel with debug info“.
Analýza objektového souboru generovaného programem se struct sample na stroji typu i386 vede na:
i386$ pahole sizes.o
struct sample {
char c[2]; /* 0 2 */
/* XXX 2 bytes hole, try to pack */
long int l; /* 4 4 */
int i; /* 8 4 */
void * p; /* 12 4 */
short int s; /* 16 2 */
/* size: 20, cachelines: 1, members: 5 */
/* sum members: 16, holes: 1, sum holes: 2 */
/* padding: 2 */
/* last cacheline: 20 bytes */
};
Každému prvku struktury jsou přiřazena dvě čísla vypsaná jako C komentáře. První číslo reprezentuje posun [offset] prvku od začátku struktury, druhé je velikost v bytech. Na konci struktury pahole shrne detaily o velikosti a dírách ve struktuře.
Podobně analýza objektového souboru generovaného programem se struct sample na stroji x86_64 vede na:
x86_64$ pahole sizes.o
struct sample {
char c[2]; /* 0 2 */
/* XXX 6 bytes hole, try to pack */
long int l; /* 8 8 */
int i; /* 16 4 */
/* XXX 4 bytes hole, try to pack */
void * p; /* 24 8 */
short int s; /* 32 2 */
/* size: 40, cachelines: 1, members: 5 */
/* sum members: 24, holes: 2, sum holes: 10 */
/* padding: 6 */
/* last cacheline: 40 bytes */
};
Zde si všimněte díry, která přibyla za int i a v objektovém kódu přeloženém na 32bitovém stroji nebyla. Překládat zdrojový kód vyvinutý pro i386, ale přeložený na x86_64 může znamenat plýtvat místem ještě víc, protože problémy se zarovnáváním tady narůstají kvůli osmibytovému long a ukazateli, zatímco integer zůstal čtyřbytový. Běžná chyba vývojářů, kteří portují aplikace z i386 na x86_64, je vynechání restrukturalizace struktur. To vede k většímu otisku programu v paměti, než se očekávalo. Větší datové struktury vedou k nutnosti číst víc řádek v cache, než je nutné, čímž se snižuje výkonnost.
Pahole umí navrhnout alternativní kompaktní strukturu, která reorganizuje datové prvky, pokud se použije volba --reorganize. Pahole také akceptuje volitelný --show_reorg_steps, který ukáže kroky, které vedly ke kompresi struktury.
x86_64$ pahole --show_reorg_steps --reorganize -C sample sizes.o
/* Moving 'i' from after 'l' to after 'c' */
struct sample {
char c[2]; /* 0 2 */
/* XXX 2 bytes hole, try to pack */
int i; /* 4 4 */
long int l; /* 8 8 */
void * p; /* 16 8 */
short int s; /* 24 2 */
/* size: 32, cachelines: 1, members: 5 */
/* sum members: 24, holes: 1, sum holes: 2 */
/* padding: 6 */
/* last cacheline: 32 bytes */
}
/* Moving 's' from after 'p' to after 'c' */
struct sample {
char c[2]; /* 0 2 */
short int s; /* 2 2 */
int i; /* 4 4 */
long int l; /* 8 8 */
void * p; /* 16 8 */
/* size: 24, cachelines: 1, members: 5 */
/* last cacheline: 24 bytes */
}
/* Final reorganized struct: */
struct sample {
char c[2]; /* 0 2 */
short int s; /* 2 2 */
int i; /* 4 4 */
long int l; /* 8 8 */
void * p; /* 16 8 */
/* size: 24, cachelines: 1, members: 5 */
/* last cacheline: 24 bytes */
}; /* saved 16 bytes! */
Algoritmus --reorganize se snaží strukturu zhustit tím, že datové prvky z konce struktury přesouvá tak, aby zaplnil díry. Snaží se vyplňující volné místo přesunout na konec struktury. Degraduje bitová pole na menší základní typ, pokud má použitý typ víc bitů, než je prvkem v bitovém poli využíváno – například int flag:1 bude degradováno na char.
Přílišná snaha strukturu zhustit nicméně může občas výkonnost poškodit. Zápisy do datových prvků mohou vynutit zápis řádek v cache jiných datových prvků, které byly načteny ze stejného řádku v cache. Některé struktury jsou tedy definovány s ____cacheline_aligned, čímž se vynutí, aby začínaly od začátku čerstvého řádku v cache. Příklad výstupu struktury, ve které se použilo ____cacheline_aligned z drivers/net/e100.c:
struct nic {
/* Begin: frequently used values: keep adjacent for cache
* effect */
u32 msg_enable ____cacheline_aligned;
struct net_device *netdev;
struct pci_dev *pdev;
struct rx *rxs ____cacheline_aligned;
struct rx *rx_to_use;
struct rx *rx_to_clean;
struct rfd blank_rfd;
enum ru_state ru_running;
spinlock_t cb_lock ____cacheline_aligned;
spinlock_t cmd_lock;
<výstup zkrácen>
Analýza struktury nic pomocí pahole ukáže díry těsně před hranicí řádku v cache, před prvky rxs a cb_lock.
x86_64$ pahole -C nic /space/kernels/linux-2.6/drivers/net/e100.o
struct nic {
u32 msg_enable; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct net_device * netdev; /* 8 8 */
struct pci_dev * pdev; /* 16 8 */
/* XXX 40 bytes hole, try to pack */
/* --- cacheline 1 boundary (64 bytes) --- */
struct rx * rxs; /* 64 8 */
struct rx * rx_to_use; /* 72 8 */
struct rx * rx_to_clean; /* 80 8 */
struct rfd blank_rfd; /* 88 16 */
enum ru_state ru_running; /* 104 4 */
/* XXX 20 bytes hole, try to pack */
/* --- cacheline 2 boundary (128 bytes) --- */
spinlock_t cb_lock; /* 128 4 */
spinlock_t cmd_lock; /* 132 4 */
<výstup zkrácen>
Kromě zaplňování děr lze pahole použít k umístění datových polí na konkrétní vzdálenost od začátku struktury. Pahole také může vypsat velikosti všech datových struktur:
x86_64$ pahole --sizes linux-2.6/vmlinux | sort -k3 -nr | head -5 tty_struct 1328 10 vc_data 432 9 request_queue 2272 8 net_device 1536 8 mddev_s 792 8
První pole reprezentuje jméno struktury, další současnou velikost a poslední počet děr ve struktuře.
Podobně lze získat shrnutí pro datové struktury, které lze zhustit, aby se zmenšila jejich spotřeba paměti:
x86_64$ pahole --packable sizes.o sample 40 24 16
První pole reprezentuje strukturu, další současnou velikost, třetí velikost po zhuštění a čtvrté celkový počet bytů ušetřený odstraněním děr.
Nástroj pfunct ukazuje vlastnosti funkcí v objektovém kódu. Umí zobrazit počet návěští pro goto, počet parametrů funkcí, velikost funkcí atd. Nejpopulárnější použití je ale nalezení počtu funkcí, které jsou deklarovány jako inline, ale inlinovány nebyly, či počet funkcí, které nebyly deklarovány inline, ale inlinovány byly. Překladač se snaží optimalizovat funkce inlinováním v závislosti na velikosti.
x86_64$ pfunct --cc_inlined linux-2.6/vmlinux | tail -5 run_init_process do_initcalls zap_identity_mappings clear_bss copy_bootdata
Překladač se také může rozhodnout zrušit inlinování funkcí, které byly specificky deklarovány jako inline. To se může stát z několika důvodů, jako je například rekurzivní volání, kde by inlinování způsobilo nekonečnou smyčku. pfunct --cc_inlined ukazuje funkce, které byly deklarovány inline, ale překladač to zrušil. Takové funkce jsou dobrými kandidáty na kontrolu nebo úplné odstranění deklarace inline. pfunct --cc_uninlined naštěstí u vmlinux (pouze) nezobrazilo žádné funkce.
Nástroje závisí na sekci debug_info objektového souboru, která je k dispozici, když je zdrojový kód přeložen s použitím ladící volby. Nástroje, které jsou součástí projektu pahole, umí použít standard DWARF nebo kompaktní C-Type formát (CTF), což jsou běžné formáty ladících souborů využívané většinou překladačů. GCC používá formát DWARF.
Ladící data jsou organizována do sekce debug_info ELF (Executable and Linkage Format, spustitelný a linkovaný formát) v podobě značek s hodnotami, které reprezentují proměnné, parametry funkcí atd. a které jsou uloženy v hierarchickém vnořovaném formátu. Čisté informace lze přečíst pomocí readelf, které je součástí binutils, nebo eu-readelf, které je součástí elfutils. Většina standardních distribucí balíčky překládá bez ladících informací, protože kvůli nim binárky bývají poměrně velké. Místo toho tyto informace poskytují jako balíčky s ladícími informacemi, které lze analyzovat těmito nástroji nebo pomocí gdb.
Nástroje zmíněné v tomto článku byly původně vyvinuty k analýze objektových souborů jádra. Nejsou nicméně omezeny na objektové soubory jádra a lze je použít na jakýkoliv program pro uživatelský prostor, pro který jsou vygenerovány ladící informace. Zdrojový kód nástrojů pahole je spravován na git://git.kernel.org/pub/scm/linux/kernel/git/acme/pahole.git. Více informací o pahole a dalších nástrojích pro analýzu ladících objektových souborů lze nalézt v PDF o sedmi trpaslících.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Ano, mohou být použity pro jakýkoli binární s trpasličí / CTF info, například si můžete na x86_64 strojově analyzovat jeden objekt PPC souboru.
Je nám líto, ale toto bylo provedeno pomocí Google Translate, doufám, že je dost dobrý,
Arnaldo