drgn/libdrgn/language.c

// Copyright (c) Meta Platforms, Inc. and affiliates.
// SPDX-License-Identifier: LGPL-2.1-or-later

#include <assert.h>

#include "array.h"
#include "language.h"
#include "util.h"

const struct drgn_language * const drgn_languages[] = {
	[DRGN_LANGUAGE_C] = &drgn_language_c,
	[DRGN_LANGUAGE_CPP] = &drgn_language_cpp,
};
static_assert(array_size(drgn_languages) == DRGN_NUM_LANGUAGES,
	      "missing language in drgn_languages");

LIBDRGN_PUBLIC const char *drgn_language_name(const struct drgn_language *lang)
{
	return lang->name;
}
Update copyright headers to Meta Signed-off-by: Omar Sandoval <osandov@osandov.com> 2021-11-21 23:59:44 +00:00			`// Copyright (c) Meta Platforms, Inc. and affiliates.`
Relicense drgn from GPLv3+ to LGPLv2.1+ drgn is currently licensed as GPLv3+. Part of the long term vision for drgn is that other projects can use it as a library providing programmatic interfaces for debugger functionality. A more permissive license is better suited to this goal. We decided on LGPLv2.1+ as a good balance between software freedom and permissiveness. All contributors not employed by Meta were contacted via email and consented to the license change. The only exception was the author of commit c4fbf7e5896c ("libdrgn: fix for compilation error"), who did not respond. That commit reverted a single line of code to one originally written by me in commit 640b1c011df8 ("libdrgn: embed DWARF index in DWARF info cache"). Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-11-02 00:05:16 +00:00			`// SPDX-License-Identifier: LGPL-2.1-or-later`
libdrgn: put language definitions in one array This way, languages can be identified by an index, which will be useful for adding Python bindings for drgn_language and for adding a language field to drgn_type. 2020-02-21 22:55:52 +00:00
Fix various lints Some functions that could be static found by -Wmissing-prototypes, some include-what-you-use warnings, some missing SPDX identifiers. These lints should be automated at some point. Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-02-17 18:45:42 +00:00			`#include <assert.h>`

libdrgn: don't store language structures in one array In the next change, we want to export languages to the public libdrgn interface. I couldn't figure out any way to export array elements as their own symbols. I'd also rather not export the drgn_languages array indices as an enum because that would preclude ever having any sort of language plugin support. Instead, let's get rid of the drgn_languages array as it currently exists and have separate drgn_language structures. This also allows us to make a bunch of the C implementation functions static again. We keep the language numbers so that we can store per-language data efficiently (currently drgn_program::void_types and languages_py), as well as a drgn_languages array to go from the language number to the struct drgn_language. But, this is all internal and could be changed if we ever support language plugins. Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-02-16 20:43:36 +00:00			`#include "array.h"`
libdrgn: put language definitions in one array This way, languages can be identified by an index, which will be useful for adding Python bindings for drgn_language and for adding a language field to drgn_type. 2020-02-21 22:55:52 +00:00			`#include "language.h"`
Fix various lints Some functions that could be static found by -Wmissing-prototypes, some include-what-you-use warnings, some missing SPDX identifiers. These lints should be automated at some point. Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-02-17 18:45:42 +00:00			`#include "util.h"`
libdrgn: put language definitions in one array This way, languages can be identified by an index, which will be useful for adding Python bindings for drgn_language and for adding a language field to drgn_type. 2020-02-21 22:55:52 +00:00
libdrgn: don't store language structures in one array In the next change, we want to export languages to the public libdrgn interface. I couldn't figure out any way to export array elements as their own symbols. I'd also rather not export the drgn_languages array indices as an enum because that would preclude ever having any sort of language plugin support. Instead, let's get rid of the drgn_languages array as it currently exists and have separate drgn_language structures. This also allows us to make a bunch of the C implementation functions static again. We keep the language numbers so that we can store per-language data efficiently (currently drgn_program::void_types and languages_py), as well as a drgn_languages array to go from the language number to the struct drgn_language. But, this is all internal and could be changed if we ever support language plugins. Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-02-16 20:43:36 +00:00			`const struct drgn_language * const drgn_languages[] = {`
			`[DRGN_LANGUAGE_C] = &drgn_language_c,`
			`[DRGN_LANGUAGE_CPP] = &drgn_language_cpp,`
libdrgn: put language definitions in one array This way, languages can be identified by an index, which will be useful for adding Python bindings for drgn_language and for adding a language field to drgn_type. 2020-02-21 22:55:52 +00:00			`};`
libdrgn: don't store language structures in one array In the next change, we want to export languages to the public libdrgn interface. I couldn't figure out any way to export array elements as their own symbols. I'd also rather not export the drgn_languages array indices as an enum because that would preclude ever having any sort of language plugin support. Instead, let's get rid of the drgn_languages array as it currently exists and have separate drgn_language structures. This also allows us to make a bunch of the C implementation functions static again. We keep the language numbers so that we can store per-language data efficiently (currently drgn_program::void_types and languages_py), as well as a drgn_languages array to go from the language number to the struct drgn_language. But, this is all internal and could be changed if we ever support language plugins. Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-02-16 20:43:36 +00:00			`static_assert(array_size(drgn_languages) == DRGN_NUM_LANGUAGES,`
			`"missing language in drgn_languages");`
libdrgn: export drgn_language instances libdrgn currently exports struct drgn_language pointers from drgn_program_language(), drgn_type_language(), and drgn_object_language(), but doesn't provide any way to do anything with them. Export our drgn_language instances and add drgn_language_name() so that they can at least be compared and printed. Signed-off-by: Omar Sandoval <osandov@osandov.com> 2022-02-16 21:05:28 +00:00
			`LIBDRGN_PUBLIC const char drgn_language_name(const struct drgn_language lang)`
			`{`
			`return lang->name;`
			`}`