binutils-gdb/libctf/ChangeLog

51 lines
1.1 KiB
Plaintext
Raw Normal View History

libctf: mmappable archives If you need to store a large number of CTF containers somewhere, this provides a dedicated facility for doing so: an mmappable archive format like a very simple tar or ar without all the system-dependent format horrors or need for heavy file copying, with built-in compression of files above a particular size threshold. libctf automatically mmap()s uncompressed elements of these archives, or uncompresses them, as needed. (If the platform does not support mmap(), copying into dynamically-allocated buffers is used.) Archive iteration operations are partitioned into raw and non-raw forms. Raw operations pass thhe raw archive contents to the callback: non-raw forms open each member with ctf_bufopen() and pass the resulting ctf_file_t to the iterator instead. This lets you manipulate the raw data in the archive, or the contents interpreted as a CTF file, as needed. It is not yet known whether we will store CTF archives in a linked ELF object in one of these (akin to debugdata) or whether they'll get one section per TU plus one parent container for types shared between them. (In the case of ELF objects with very large numbers of TUs, an archive of all of them would seem preferable, so we might just use an archive, and add lzma support so you can assume that .gnu_debugdata and .ctf are compressed using the same algorithm if both are present.) To make usage easier, the ctf_archive_t is not the on-disk representation but an abstraction over both ctf_file_t's and archives of many ctf_file_t's: users see both CTF archives and raw CTF files as ctf_archive_t's upon opening, the only difference being that a raw CTF file has only a single "archive member", named ".ctf" (the default if a null pointer is passed in as the name). The next commit will make use of this facility, in addition to providing the public interface to actually open archives. (In the future, it should be possible to have all CTF sections in an ELF file appear as an "archive" in the same fashion.) This machinery is also used to allow library-internal creators of ctf_archive_t's (such as the next commit) to stash away an ELF string and symbol table, so that all opens of members in a given archive will use them. This lets CTF archives exploit the ELF string and symbol table just like raw CTF files can. (All this leads to somewhat confusing type naming. The ctf_archive_t is a typedef for the opaque internal type, struct ctf_archive_internal: the non-internal "struct ctf_archive" is the on-disk structure meant for other libraries manipulating CTF files. It is probably clearest to use the struct name for struct ctf_archive_internal inside the program, and the typedef names outside.) libctf/ * ctf-archive.c: New. * ctf-impl.h (ctf_archive_internal): New type. (ctf_arc_open_internal): New declaration. (ctf_arc_bufopen): Likewise. (ctf_arc_close_internal): Likewise. include/ * ctf.h (CTFA_MAGIC): New. (struct ctf_archive): New. (struct ctf_archive_modent): Likewise. * ctf-api.h (ctf_archive_member_f): New. (ctf_archive_raw_member_f): Likewise. (ctf_arc_write): Likewise. (ctf_arc_close): Likewise. (ctf_arc_open_by_name): Likewise. (ctf_archive_iter): Likewise. (ctf_archive_raw_iter): Likewise. (ctf_get_arc): Likewise.
2019-04-24 12:30:17 +02:00
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-archive.c: New.
* ctf-impl.h (ctf_archive_internal): New type.
(ctf_arc_open_internal): New declaration.
(ctf_arc_bufopen): Likewise.
(ctf_arc_close_internal): Likewise.
libctf: opening This fills in the other half of the opening/creation puzzle: opening of already-existing CTF files. Such files are always read-only: if you want to add to a CTF file opened with one of the opening functions in this file, use ctf_add_type(), in a later commit, to copy appropriate types into a newly ctf_create()d, writable container. The lowest-level opening functions are in here: ctf_bufopen(), which takes ctf_sect_t structures akin to ELF section headers, and ctf_simple_open(), which can be used if you don't have an entire ELF section header to work from. Both will malloc() new space for the buffers only if necessary, will mmap() directly from the file if requested, and will mprotect() it afterwards to prevent accidental corruption of the types. These functions are also used by ctf_update() when converting types in a writable container into read-only types that can be looked up using the lookup functions (in later commits). The files are always of the native endianness of the system that created them: at read time, the endianness of the header magic number is used to determine whether or not the file needs byte-swapping, and the entire thing is aggressively byte-swapped. The agggressive nature of this swapping avoids complicating the rest of the code with endianness conversions, while the native endianness introduces no byte-swapping overhead in the common case. (The endianness-independence code is also much newer than everything else in this file, and deserves closer scrutiny.) The accessors at the top of the file are there to transparently support older versions of the CTF file format, allowing translation from older formats that have different sizes for the structures in ctf.h: currently, these older formats are intermingled with the newer ones in ctf.h: they will probably migrate to a compatibility header in time, to ease readability. The ctf_set_base() function is split out for the same reason: when conversion code to a newer format is written, it would need to malloc() new storage for the entire ctf_file_t if a file format change causes it to grow, and for that we need ctf_set_base() to be a separate function. One pair of linked data structures supported by this file has no creation code in libctf yet: the data and function object sections read by init_symtab(). These will probably arrive soon, when the linker comes to need them. (init_symtab() has hardly been changed since 2009, but if any code in libctf has rotted over time, this will.) A few simple accessors are also present that can even be called on read-only containers because they don't actually modify them, since the relevant things are not stored in the container but merely change its operation: ctf_setmodel(), which lets you specify whether a container is LP64 or not (used to statically determine the sizes of a few types), ctf_import(), which is the only way to associate a parent container with a child container, and ctf_setspecific(), which lets the caller associate an arbitrary pointer with the CTF container for any use. If the user doesn't call these functions correctly, libctf will misbehave: this is particularly important for ctf_import(), since a container built against a given parent container will not be able to resolve types that depend on types in the parent unless it is ctf_import()ed with a parent container with the same set of types at the same IDs, or a superset. Possible future extensions (also noted in the ctf-hash.c file) include storing a count of things so that we don't need to do one pass over the CTF file counting everything, and computing a perfect hash at CTF creation time in some compact form, storing it in the CTF file, and using it to hash things so we don't need to do a second pass over the entire CTF file to set up the hashes used to go from names to type IDs. (There are multiple such hashes, one for each C type namespace: types, enums, structs, and unions.) libctf/ * ctf-open.c: New file. * swap.h: Likewise. include/ * ctf-api.h (ctf_file_close): New declaration. (ctf_getdatasect): Likewise. (ctf_parent_file): Likewise. (ctf_parent_name): Likewise. (ctf_parent_name_set): Likewise. (ctf_import): Likewise. (ctf_setmodel): Likewise. (ctf_getmodel): Likewise. (ctf_setspecific): Likewise. (ctf_getspecific): Likewise.
2019-04-24 11:17:13 +02:00
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-open.c: New file.
* swap.h: Likewise.
libctf: creation functions The CTF creation process looks roughly like (error handling elided): int err; ctf_file_t *foo = ctf_create (&err); ctf_id_t type = ctf_add_THING (foo, ...); ctf_update (foo); ctf_*write (...); Some ctf_add_THING functions accept other type IDs as arguments, depending on the type: cv-quals, pointers, and structure and union members all take other types as arguments. So do 'slices', which let you take an existing integral type and recast it as a type with a different bitness or offset within a byte, for bitfields. One class of THING is not a type: "variables", which are mappings of names (in the internal string table) to types. These are mostly useful when encoding variables that do not appear in a symbol table but which some external user has some other way to figure out the address of at runtime (dynamic symbol lookup or querying a VM interpreter or something). You can snapshot the creation process at any point: rolling back to a snapshot deletes all types and variables added since that point. You can make arbitrary type queries on the CTF container during the creation process, but you must call ctf_update() first, which translates the growing dynamic container into a static one (this uses the CTF opening machinery, added in a later commit), which is quite expensive. This function must also be called after adding types and before writing the container out. Because addition of types involves looking up existing types, we add a little of the type lookup machinery here, as well: only enough to look up types in dynamic containers under construction. libctf/ * ctf-create.c: New file. * ctf-lookup.c: New file. include/ * ctf-api.h (zlib.h): New include. (ctf_sect_t): New. (ctf_sect_names_t): Likewise. (ctf_encoding_t): Likewise. (ctf_membinfo_t): Likewise. (ctf_arinfo_t): Likewise. (ctf_funcinfo_t): Likewise. (ctf_lblinfo_t): Likewise. (ctf_snapshot_id_t): Likewise. (CTF_FUNC_VARARG): Likewise. (ctf_simple_open): Likewise. (ctf_bufopen): Likewise. (ctf_create): Likewise. (ctf_add_array): Likewise. (ctf_add_const): Likewise. (ctf_add_enum_encoded): Likewise. (ctf_add_enum): Likewise. (ctf_add_float): Likewise. (ctf_add_forward): Likewise. (ctf_add_function): Likewise. (ctf_add_integer): Likewise. (ctf_add_slice): Likewise. (ctf_add_pointer): Likewise. (ctf_add_type): Likewise. (ctf_add_typedef): Likewise. (ctf_add_restrict): Likewise. (ctf_add_struct): Likewise. (ctf_add_union): Likewise. (ctf_add_struct_sized): Likewise. (ctf_add_union_sized): Likewise. (ctf_add_volatile): Likewise. (ctf_add_enumerator): Likewise. (ctf_add_member): Likewise. (ctf_add_member_offset): Likewise. (ctf_add_member_encoded): Likewise. (ctf_add_variable): Likewise. (ctf_set_array): Likewise. (ctf_update): Likewise. (ctf_snapshot): Likewise. (ctf_rollback): Likewise. (ctf_discard): Likewise. (ctf_write): Likewise. (ctf_gzwrite): Likewise. (ctf_compress_write): Likewise.
2019-04-23 23:45:46 +02:00
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-create.c: New file.
* ctf-lookup.c: New file.
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-impl.h: New definitions and declarations for type creation
and lookup.
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-hash.c: New file.
* ctf-impl.h: New declarations.
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-error.c: New file.
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-util.c: New file.
* elf.h: Likewise.
* ctf-impl.h: Include it, and add declarations.
2019-05-28 Nick Alcock <nick.alcock@oracle.com>
* ctf-impl.h: New file.
* ctf-subr.c: New file.
Local Variables:
mode: change-log
left-margin: 8
fill-column: 76
version-control: never
End: