Some gdbserver targets generate their target description based on the
gdb/regformats/*.dat files. These .dat files are generated from a
matching xml file in gdb/features/.
Lets consider a concrete example:
Take gdb/features/or1k-linux.xml, this file is processed by
gdb/features/Makefile to create gdb/regformats/or1k-linux.dat.
When gdbserver is built for the or1k target the file
or1k-linux-generated.cc is generated using the
gdb/regformats/regdat.sh script. This .cc file is then compiled and
linked into gdbserver.
The or1k-linux-generated.cc file contains the function
init_registers_or1k_linux which is called from within gdbserver, this
function creates a target_desc object and sets its xmltarget field to
a fixed string. This fixed string is the xml filename that was
originally used to generate the xml file, in this case or1k-linux.xml.
Additionally, as part of the gdbserver build the file or1k-linux.xml
is converted to a string and placed in the file
xml-builtin-generated.cc which is then built into gdbserver.
Now when GDB asks gdbserver for the target description, gdbserver
returns the fixed xmltarget string, which is the name of an xml file.
GDB will then ask gdbserver for that file and gdbserver will return
the contents of that file thanks to the xml-builtin-generated.cc
file's contents.
This is all rather complicated, but it does work. So what's the
problem that I'm fixing?
Well or1k-linux.xml does contain the osabi information, so this will
be returned from gdbserver to GDB. That's good.
However, the target_desc object created in init_registers_or1k_linux
will not have its osabi set correctly.
Now this doesn't really matter too much except
init_registers_or1k_linux includes a call to init_target_desc.
In the next commit I want to extend init_target_desc to require an
osabi to be passed in. The motivation for this will be explained in
the next commit, but if we accept for a moment that this is something
that should be done, then the question is what osabi should we use in
init_registers_or1k_linux?
Ideally we'd use the osabi which is set in or1k-linux.xml. If we do
that then everything will remain consistent, which is a good thing.
And so, to get the osabi from or1k-linux.xml into
init_registers_or1k_linux, we first need to get the osabi information
into or1k-linux.dat file, and this is what this commit does.
I've added a new xsl script print-osabi.xsl and updated
gdb/features/Makefile to make use of this script. Then I regenerated
all of the .dat files. Now every .dat file contains either:
osabi:GNU/Linux
osabi:unknown
The first is for xml files containing <osabi>GNU/Linux</osabi> and the
second is for xml files that don't contain an osabi element.
This commit doesn't attempt to make use of the osabi information in
the .dat files, that will come in the next commit. There should be no
user visible changes after this commit.
Approved-By: Kevin Buettner <kevinb@redhat.com>
Some of the top level (i.e. those that contain the <target> element)
xml files in gdb/features/ are clearly Linux only. I conclude this
based on the files names containing the string "linux".
I think that all of these files should have the <osabi> element
included with the value "GNU/Linux".
This commits adds the <osabi> element where I believe it is
appropriate and regenerates the associated .c files.
The benefit of this change is that gdbserver, which makes use of these
files, will now send the osabi back in more cases. Sending back more
descriptive target descriptions is a good thing as this makes it
easier for GDB to select the correct gdbarch.
Approved-By: Kevin Buettner <kevinb@redhat.com>
The test gdb.reverse/i386-avx-reverse.exp was changed by the recent
commit:
commit 5bf288d5a8
Author: Guinevere Larsen <guinevere@redhat.com>
Date: Fri Jul 26 17:31:14 2024 -0300
gdb/record: support AVX instructions VMOVDQ(U|A) when recording
In that commit I added a few calls to the instruction vmovdqa to and
from memory addresses. Because my local gcc testing always had aligned
pointers, I thought this would always work, but clang (and maybe other
compilers) might not do the same, which will cause vmovdqa to segfault,
and the test to fail spectacularly.
This commit fixes that by using the pre-existing precise-aligned-alloc
to allocate the dynamic buffers, forcing them to be aligned to the
required boundary for vmovdqa instruction to work. The code was then
re-shuffled to keep the current clustering of instructions.
Approved-By: Tom Tromey <tom@tromey.com>
In gdb/aarch64-linux-tdep.c we find:
...
gdb::byte_vector za_zeroed (za_bytes, 0);
regcache->raw_supply (tdep->sme_za_regnum, za_zeroed);
...
We can't use reg_buffer::raw_supply_zeroed here because only part of the
register is written.
Add raw_supply_part_zeroed, and use it instead.
Likewise elsewhere in AArch64 tdep code.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
sec_merge_hash.size duplicates sec_merge_hash.table.count, albeit using
bfd_size_type rather than unsigned int. The only reason to have the
duplicate field is to catch unsigned int overflows, and that can be
done easily enough when and if required. Overflow isn't possible at
the moment. See the needs_resize comment.
* merge.c (sec_merge_hash): Remove "size" field.
(NEEDS_RESIZE): Delete macro, replacing with..
(needs_resize): ..this inline function.
(sec_merge_resize): Rename from sec_merge_maybe_resize,
removing redundant check.
(sec_merge_hash_insert, sec_merge_hash_lookup): Adjust to suit.
(sec_merge_init, merge_strings): Likewise.
Fix csky-linux-gnu FAIL of ld-elf/pr32341, due to that target having
its own .bss directive.
PR ld/32341
* testsuite/ld-elf/pr32341.s: Don't use .bss directive. Specify
progbits/nobits on all .section directives.
Commit 8b5a212495 supported *ABS* symbols by allowing "section" to be
bfd_abs_section, but bfd_abs_section needs to be treated specially.
In particular, bfd_get_next_section_by_name (.., bfd_abs_section_ptr)
is invalid.
PR 32347
* tekhex.c (first_phase): Guard against modification of
_bfd_std_section[] entries.
Due to a logical bug in gdb/cp-support.c:cp_search_name_hash(), GDB
may not be able to find a symbol when asked by the user. See the
accompanying test for such demonstration.
The cp_search_name_hash() cannot correctly handle a (demangled) symbol
that comprises of type-casting for the first parameter in its template
parameter list, e.g.:
foo<(enum_test)0>(int, int)
In this example, the processing logic in cp_search_name_hash() considers
the "foo<" string for hashing instead of "foo". This is due to a faulty
logic in the processing loop that tries to _keep_ hashing if a '<' char
with the following property is encountered:
---------------------------------------------------------------------
for (const char *string = search_name; *string != '\0'; ++string)
{
...
if (*string == '(')
break;
...
/* Ignore template parameter list. */
if (string[0] == '<'
&& string[1] != '(' && string[1] != '<' && string[1] != '='
&& string[1] != ' ' && string[1] = '\0')
break;
...
hash = SYMBOL_HASH_NEXT (hash, *string);
}
---------------------------------------------------------------------
Ostensibly, this logic strives to bail out of the processing loop as
soon as the beginning of an argument list is encountered, "(int, int)"
in the example, or the beginning of a template parameter list, the
"<(enum_test)0>" in the example. However, when "string" is pointing
at '<', the following incorrect logic takes precedence:
---------------------------------------------------------------------
for (const char *string = search_name; *string != '\0'; ++string)
{
if (*string == '(')
break;
...
if (string[0] == '<' && string[1] != '(' ...)
break;
hash = SYMBOL_HASH_NEXT (hash, *string);
}
---------------------------------------------------------------------
In "foo<(enum_test)0>(int, int)", the '(' char that is positioned after
the '<' char causes the "if" condition at the end of the loop not to
"break". As a result, the '<' is considered for hashing and at the
beginning of the next iteration, the loop is exited because "string"
points to '(' char.
It's obvious that the intention of the "if" condition at the end of the
loop body is to handle cases where the method name is "operator<",
"operator<<", or "operator<=". While fixing the issue, I've re-written
the logic as such to make that more explicit. Still, the complexity of
the function remains O(n). It is worth mentioning that in the same
file the "find_toplevel_char()" follows the same explicit logic.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
Reviewed-By: Pedro Alves <pedro@palves.net>
Approved-by: Tom Tromey <tom@tromey.com>
Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e
This simplifies things a little bit, removing some `find_if` when
inserting or removing objfiles, and the whole
unwrapping_objfile_iterator thing.
Change-Id: Idd1851d36c7834820c9c1639a6a252de643eafba
Currently, when you're already less than a page from the top in the TUI
source window, and you press Page-Up, nothing happens, while I would
expect that it then scrolls the source up to the first line.
It's happening because scrolling a full page up would result in a
negative starting line number, which is then checked if it's higher than
the (unsigned) number of available lines, and since this will always be
true, the original starting line number is restored.
Afterwards it would check if the line number is too low, but since the
negative value was already gone, it didn't do much.
Fixed by moving the low line number check before the maximum line number
check.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that in commit:
commit 5cabc8098e
Date: Wed Jul 31 15:55:57 2024 +0100
gdb/python: implement Python find_exec_by_build_id hook
I managed to typo 'unsupported' as 'unsupport'. If you run the test
on a target that doesn't support core file creation then you'll get a
TCL error.
Fixed in this commit.
I ran into an unexpected failure in gdb.base/info_sources.exp. The
test in question runs this command:
(gdb) info sources -d -- -d
That is, list all the source files whose directory name matches the
regexp '-d'. The expectation is that no source files will be listed.
Unfortunately, when I ran the test some source files are listed; the
directory I am running in contains the pattern '-d', and so the test
fails.
As we cannot control where the developer is building and testing GDB,
I propose that instead of just testing with '-d' we should search
through all the letters a-z and find one that isn't present in the
source file directory name. I'm still including the leading '-'
character in the regexp.
So now, unless GDB is being built in a directory that contains '-a',
'-b', '-c', .... '-z', the test will find one letter which isn't
present, and use that for the test.
To avoid test names changing between runs in different directories
I've had to tweak the test name to something more generic, but there
should be no change in which parts of GDB are actually being tested.
Approved-By: Tom Tromey <tom@tromey.com>
With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran
into:
...
(gdb) core-file solib-with-soname.core^M
Downloading 197.86 K file libfoo_1.so...^M
[New LWP 997314]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Core was generated by `solib-with-soname'.^M
Program terminated with signal SIGABRT, Aborted.^M
(gdb) FAIL: $exp: load core file, use debuginfod: load core file
...
The test-case doesn't expect the "197.86 K" part.
The same problem was fixed for another test-case in commit a723c56efb
("gdb/testsuite: avoid intermittent failures on a debuginfod test").
Fix this in the same way: by updating the regexp.
Tested on aarch64-linux.
PR testsuite/32354
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32354
This patch changes block::get_using to return an iterator range. This
seemed cleaner to me than the current approach of returning a pointer
to the first using directive; all the callers actually use this to
iterate.
When building a help string, it's possible that the resulting options
will go over 80 columns. This patch changes this code to add line
wrapping where needed.
This can most be seen by looking "help bt" and in particular the
"-frame-info" help text.
The help text for various "internal problem" settings is longer than
80 columns. This patch tightens this up a bit. Note that these
commands are all "maint" commands so, IMO, it is sufficient if they
are clear to a gdb developer.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
The help for remote packet controls includes the "title". However
this is is just the parameter name, and not really useful to see
repeated in the help text.
Approved-By: Eli Zaretskii <eliz@gnu.org>
The opaque-type-resolution help says "if set before loading symbols",
but I don't think this is accurate. As far as I know, this resolution
can be done at any time.
This patch cleans up the help, also shortening it to less than 80
characters.
Approved-By: Eli Zaretskii <eliz@gnu.org>
This patch ensures that all ordinary help strings are wrapped at 80
columns. For the most part this consists of changing code like this
(note the embedded \n and the trailing backslash without a newline):
-Manage the space-separated list of debuginfod server URLs that GDB will query \
-when missing debuginfo, executables or source files.\nThe default value is \
-copied from the DEBUGINFOD_URLS environment variable."),
... to end each line with \n\, like:
+Manage the space-separated list of debuginfod server URLs that GDB will\n\
+query when missing debuginfo, executables or source files.\n\
+The default value is copied from the DEBUGINFOD_URLS environment variable."),
Approved-By: Eli Zaretskii <eliz@gnu.org>
If you invoke "help function _caller_is", you'll see that the help
text is indented strangely. The fix for this is to add a call to
gdbpy_fix_doc_string_indentation in the appropriate spot, as is
already done for Python commands and parameters.
A customer noted that there is no way to prevent the "current language
does not match this frame" warning. This patch adds a new setting to
allow this warning to be suppressed.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Fixed missing operator % on xmethod matcher registration output and, as
suggested on bug 32532, converted both uses of operator % to str.format.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32352
Change-Id: Ic471516292c2f1d6d1284aaeaea3ec14421decb8
Move note sections after .rodata section so that note sections are
placed in the same PT_LOAD segment together with .rodata section,
instead of a separate PT_LOAD segment.
PR ld/32341
* scripttempl/misc-sections.sc: Move note sections to ...
* scripttempl/elf.sc: Here, after .rodata section.
* testsuite/ld-elf/pr32341.d: New file.
* testsuite/ld-elf/pr32341.s: Likewise.
Co-Authored-By: Nick Clifton <nickc@redhat.com>
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
I recently came across a case where a compiler would emit a CU with an
empty name. In such case, the attribute object constructed by GDB will
return nullptr when as_string is called. One place is not checking for
this possibility. As a result, loading such binary results in a GDB
crash:
$ gdb -q a.out
Reading symbols from a.out...
Fatal signal: Segmentation fault
----- Backtrace -----
[...]
0x742f4dd8afab __strcmp_avx2
../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
0x58593704a0bc prepare_one_comp_unit
../../gdb/dwarf2/read.c:21842
0x585937053fd9 process_psymtab_comp_unit
../../gdb/dwarf2/read.c:4633
0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_
../../gdb/dwarf2/read.c:4943
[...]
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
This seems to be a regression introduced by the following commit:
commit 00105aa1c4
Date: Tue Sep 24 10:24:22 2024 +0200
[gdb/symtab] Don't expand non-Ada CUs for info exceptions
This patch fixes this issue by checking if attr->as_string returns
nullptr.
Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
commit 8f6c452b5a
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
gdb.missing_objfile.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Add a new ext_lang_find_objfile_from_buildid function which is called
from find_objfile_by_build_id and gives extension languages a chance
to find missing objfiles.
This commit adds the ext_lang_find_objfile_from_buildid function and
the extension_language_ops::find_objfile_from_buildid() hook, but does
not implement the hook for any extension languages, that will come in
the next commit.
This commit does rewrite find_objfile_by_build_id (build-id.c) to call
the new hook though. The basic steps of find_objfile_by_build_id are
now this:
1. Try to find the missing objfile using the build-id by looking in
the debug-file-directory's .build-id/ sub-directory. If we find the
file then we're done.
2. Ask debuginfod to download the missing file for us. If we
download the file successfully then we're done.
3. Ask the extension language hook to find the file for us. If the
extension language asks us to try again then we repeat step (1) only
and if we still don't have the file, we move to step (4). If the
extension language told us where the file is then we use that file
and we're done.
4. We didn't find the file. Carry on without it.
Only step (3) is new in this logic, everything else was already done.
There are no tests added here as we can't currently write an extension
language callback. The next commit will add the tests.
Approved-By: Tom Tromey <tom@tromey.com>
In preparation for later commits in this series, rename
ext_lang_missing_debuginfo_result to ext_lang_missing_file_result.
A later commit will add additional Python APIs to handle different
types of missing files beyond just debuginfo.
This is just a rename commit, there should be no functional changes
after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
When opening a core-file GDB is able to use debuginfod to download the
executable that matches the core-file if GDB can find a build-id for
the executable in the core-file.
In this case GDB calls debuginfod_exec_query to download the
executable and GDB prints a message like:
Downloading executable for /path/to/core-file...
which makes sense in that case.
For a long time GDB has also had the ability to download memory-mapped
files and shared libraries when opening a core-file. However, recent
commits have made these cases more likely to trigger, which is a good
thing, but the messaging from GDB in these cases is not ideal. When
downloading a memory-mapped file GDB prints:
Downloading executable for /path/to/memory-mapped-file
And for a shared library:
Downloading executable for /path/to/libfoo.so
These last two messages could, I think, be improved.
I propose making two changes. First, I suggest instead of using
/path/to/core-file in the first case, we use the name of the
executable that GDB is fetching. This makes the messaging consistent
in that we print the name of the file we're fetching rather than the
name of the file we're fetching something for.
I further propose that we replace 'executable for' with the more
generic word 'file'. The messages will then become:
Downloading file /path/to/exec-file...
Downloading file /path/to/memory-mapped-file...
Downloading file /path/to/libfoo.so...
I think these messages are clearer than what we used to have, and they
are consistent in that we name the thing being downloaded in all
cases.
There is one tiny problem. The first case relies on GDB knowing the
name of the executable it wants to download. The only place we can
currently get that from is, I think, the memory-mapped file list.
[ ASIDE: There is `bfd_core_file_failing_command` which reports the
executable and argument list from the core file, but this
information is not ideal for this task. First, the executable and
arguments are merged into a single string, and second, the string is
a relatively short, fixed length string, so the executable name is
often truncated. For these reasons I don't consider fetching the
executable name using this bfd function as a solution. ]
We do have to consider the case that the core file does not have any
mapped file information. This shouldn't ever be the case for a Linux
target, but it's worth considering.
[ ASIDE: I mention Linux specifically because this only becomes a
problem if we try to do a lookup via debuginfod, which requires that
we have build-ids available. Linux has special support for
embedding build-ids into the core file, but I'm not sure if other
kernels do this. ]
For the unlikely edge case of a core-file that has build-ids, but
doesn't have any mapped file information then I propose that we
synthesis a filename like: 'with build-id xxxxxx'. We would then see
a message like:
Downloading file with build-id xxxxxx...
Where 'xxxxxx' would be replaced by the actual build-id.
This isn't ideal, but I think is good enough, and, as I said, I think
this case is not going to be hit very often, or maybe at all.
We already had some tests that emitted two of the above messages,
which I've updated, these cover the mapped-file and shared library
case.
The message about downloading the exec for the core-file is actually
really hard to trigger now as usually the exec will also appear in the
memory-mapped file list and GDB will download the file at this stage.
Then when GDB needs the executable for loading the symbols it'll ask
debuginfod, and debuginfod will find the file in its cache, and so no
message will be printed.
If anyone has any ideas about how to trigger this case then I'm happy
to add additional tests.
Approved-By: Tom Tromey <tom@tromey.com>
This test checks that GDB is able to load DWARF information when
.debug_aranges has a section address size that is set to 0.
This test was originally written by Jan Kratochvil to test commit
927aa2e778 from 2017, titled "DWARF-5: .debug_names index consumer".
This test was originally written using a static .S file and has
been present in the Fedora tree for a long time.
If dwarf2/aranges.c is modified to turn off the address_size check,
GDB will crash with SIGFPE when loading the executable with address
size set to zero.
I modified the DWARF assembler to make it possible to set the address
size to zero in a .debug_aranges section and used the DWARF assembler
to produce the assembly file.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>
This function doesn't seem so useful, use `process_info::pid` directly
instead.
Change-Id: I55d592f38b32a197957ed4c569993cd23a818cb4
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
This function doesn't seem so useful, use `thread_info:🆔:pid`
directly instead.
Change-Id: I7450c4223e5b0bf66788eeb5b070ab6f5287f798
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
This function doesn't seem so useful. Use `thread_info:🆔:lwp`
directly.
Change-Id: Ib4a86eeeee6c1342bc1c092f083589ce28009be1
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
This function doesn't seem so useful. Use `thread_info::id` directly.
Change-Id: I158cd06a752badd30f68424e329aa42d275e43b7
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
This function doesn't seem so useful. Use `thread_info::id` directly.
Change-Id: I4ae4e7baa44e09704631a1c3a5a66e5b8b5a3594
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
I think it just makes things more obscure. Use `thread_info::id`
directly instead.
Change-Id: I141d5fb08ebf45c13cc32c4bba62773249fcb356
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Remove the `get_thread_process` function, use `thread_info::process`
instead.
In `server.cc`, use `current_process ()` instead of going through the
current thread.
Change-Id: Ifc61d65852e392d154b854a45d45df584ab3922e
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Same idea as the previous patch, but for `remove_thread`.
Change-Id: I7e227655be5fcf29a3256e8389eb32051f27882d
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Since thread_info objects are now basically children of process_info
objects, I think that makes sense.
Change-Id: I7f0a67b921b468e512851cb2f36015d1003412d7
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
In a few spots, we need to get to a process from a thread. Having a
backlink from thread to process is cheap and makes the operation
trivial, add it.
Change-Id: I8a94b2919494b1dcaf954de2246386794308aa82
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
