Commit Graph

74 Commits

Author SHA1 Message Date
Tankut Baris Aktemur
a2cc13fad6 gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache
Boolify the 'fetch' parameter of the get_thread_regcache function.

All of the current uses pass true for this parameter.  Therefore, define
its default value as true and remove the argument from the uses.

We still keep the parameter, though, to give downstream targets the
option to obtain a regcache without having to fetch the whole
contents.  Our (Intel) downstream target is an example.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-12-17 08:48:02 +01:00
Tankut Baris Aktemur
2903d61808 gdbserver: by-pass regcache to access tdesc only
The `get_thread_regcache` function has a `fetch` option to skip
fetching the registers from the target.  It seems this option is set
to false only at uses where we just need to access the tdesc through
the regcache of the current thread, as in

  struct regcache *regcache = get_thread_regcache (current_thread, 0);
  ... regcache->tdesc ...

Since the tdesc of a regcache is set from the process of the thread
that owns the regcache, we can simplify the code to access the tdesc
via the process, as in

  ... current_process ()->tdesc ...

This is intended to be a refactoring with no behavioral change.

Tested only for the linux-x86-low target.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-12-17 08:48:02 +01:00
Tankut Baris Aktemur
038590b067 gdbserver: remove 'struct' in 'struct thread_info' declarations
Remove the 'struct' keyword in occurrences of 'struct thread_info'.
This is a code clean-up.

Tested by rebuilding.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-12-09 14:16:23 +01:00
Simon Marchi
ffa5bea793 gdbserver: remove macro get_lwp_thread
I was thinking of changing this macro to a function, but I don't think
it adds much value over just accessing the field directly.

Change-Id: I5dc63e9db0773549c5b55a1279212e2d1213f50c
Approved-By: Tom Tromey <tom@tromey.com>
2024-12-04 15:05:58 -05:00
Simon Marchi
5929ef8975 gdbserver: remove lwpid_of(thread)
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>
2024-11-08 09:16:23 -05:00
Schimpe, Christina
fc14343205 gdb, gdbserver, python, testsuite: Remove MPX.
GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel
listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019.
MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6)
and glibc (since v2.35).  Let's now remove MPX support in GDB completely.

This includes the removal of:
- MPX functionality including register support
- deprecated mpx commands
- i386 and amd64 implementation of the hooks report_signal_info and
  get_siginfo_type
- tests
- and pretty printer.

We keep MPX register numbers to not break compatibility with old gdbservers.

Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-09-25 11:06:57 +00:00
Andrew Burgess
646d754d14 gdb/gdbserver: share x86/linux tdesc caching
This commit builds on the previous series of commits to share the
target description caching code between GDB and gdbserver for
x86/Linux targets.

The objective of this commit is to move the four functions (2 each of)
i386_linux_read_description and amd64_linux_read_description into the
gdb/arch/ directory and combine them so we have just a single copy of
each.  Then GDB, gdbserver, and the in-process-agent (IPA) will link
against these shared functions.

One curiosity with this patch is the function
x86_linux_post_init_tdesc.  On the gdbserver side the two functions
amd64_linux_read_description and i386_linux_read_description have some
functionality that is not present on the GDB side, there is some
additional configuration that is performed as each target description
is created, to setup the expedited registers.

To support this I've added the function x86_linux_post_init_tdesc.
This function is called from the two *_linux_read_description
functions, but is implemented separately for GDB and gdbserver.

An alternative approach that avoids adding x86_linux_post_init_tdesc
would be to have x86_linux_tdesc_for_tid return a non-const target
description, then in x86_target::low_arch_setup we could inspect the
target description to figure out if it is 64-bit or not, and modify
the target description as needed.  In the end I think that adding the
x86_linux_post_init_tdesc function is the simpler solution.

The contents of gdbserver/linux-x86-low.cc have moved to
gdb/arch/x86-linux-tdesc-features.c, and gdbserver/linux-x86-tdesc.h
has moved to gdb/arch/x86-linux-tdesc-features.h, this change leads to
some updates in the #includes in the gdbserver/ directory.

This commit also changes how target descriptions are cached.
Previously both GDB and gdbserver used static C-style arrays to act as
the tdesc cache.  This was fine, except for two problems.  Either the
C-style arrays would need to be placed in x86-linux-tdesc-features.c,
which would allow us to use the x86_linux_*_tdesc_count_1() functions
to size the arrays for us, or we'd need to hard code the array sizes
using separate #defines, which we'd then have to keep in sync with the
rest of the code in x86-linux-tdesc-features.c.

Given both of these problems I decided a better solution would be to
just switch to using a std::unordered_map to act as the cache.  This
will resize automatically, and we can use the xcr0 value as the key.

At first inspection, using xcr0 might seem to be a problem; after all
the {i386,amd64}_create_target_description functions take more than
just the xcr0 value.  However, this patch is only for x86/Linux
targets, and for x86/Linux all of the other flags passed to the tdesc
creation functions have constant values and so are irrelevant when we
consider tdesc caching.

For testing I've done the following:

  - Built on x86-64 GNU/Linux for all targets, and just for the native
    target,

  - Build on i386 GNU/Linux for all targets, and just for the native
    target,

  - Build on a 64-bit, non-x86 GNU/Linux for all targets, just for the
    native target, and for targets x86_64-*-linux and i386-*-linux.

Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-06-14 09:08:45 +01:00
Andrew Burgess
cc59d02b90 gdbserver: update target description creation for x86/linux
This commit is part of a series which aims to share more of the target
description creation between GDB and gdbserver for x86/Linux.

After some refactoring earlier in this series the shared
x86_linux_tdesc_for_tid function was added into nat/x86-linux-tdesc.c.
However, this function still relies on amd64_linux_read_description
and i386_linux_read_description which are implemented separately for
both gdbserver and GDB.  Given that at their core, all these functions
do is:

  1. take an xcr0 value as input,
  2. mask out some feature bits,
  3. look for a cached pre-generated target description and return it
     if found,
  4. if no cached target description is found then call either
     amd64_create_target_description or
     i386_create_target_description to create a new target
     description, which is then added to the cache.  Return the newly
     created target description.

The inner functions amd64_create_target_description and
i386_create_target_description are already shared between GDB and
gdbserver (in the gdb/arch/ directory), so the only thing that
the *_read_description functions really do is add the caching layer,
and it feels like this really could be shared.

However, we have a small problem.

Despite using the same {amd64,i386}_create_target_description
functions in both GDB and gdbserver to create the target descriptions,
on the gdbserver side we cache target descriptions based on a reduced
set of xcr0 feature bits.

What this means is that, in theory, different xcr0 values can map to
the same cache entry, which could result in the wrong target
description being used.

However, I'm not sure if this can actually happen in reality.  Within
gdbserver we already split the target description cache based on i386,
amd64, and x32.  I suspect within a given gdbserver session we'll only
see at most one target description for each of these.

The cache conflicting problem is caused by xcr0_to_tdesc_idx, which
maps an xcr0 value to a enum x86_linux_tdesc value, and there are only
7 usable values in enum x86_linux_tdesc.

In contrast, on the GDB side there are 64, 32, and 16 cache slots for
i386, amd64, and x32 respectively.

On the GDB side it is much more important to cache things correctly as
a single GDB session might connect to multiple different remote
targets, each of which might have slightly different x86
architectures.

And so, if we want to merge the target description caching between GDB
and gdbserver, then we need to first update gdbserver so that it
caches in the same way as GDB, that is, it needs to adopt a mechanism
that allows for the same number of cache slots of each of i386, amd64,
and x32.  In this way, when the caching is shared, GDB's behaviour
will not change.

Unfortunately it's a little more complex than that due to the in
process agent (IPA).

When the IPA is in use, gdbserver sends a target description index to
the IPA, and the IPA uses this to find the correct target description
to use, the IPA having first generated every possible target
description.

Interestingly, there is certainly a bug here which results from only
having 7 values in enum x86_linux_tdesc.  As multiple possible target
descriptions in gdbserver map to the same enum x86_linux_tdesc value,
then, when the enum x86_linux_tdesc value is sent to the IPA there is
no way for gdbserver to know that the IPA will select the correct
target description.  This bug will get fixed by this commit.

** START OF AN ASIDE **

Back in the day I suspect this approach of sending a target
description index made perfect sense.  However since this commit:

  commit a880623024
  Date:   Thu Dec 7 17:07:01 2017 +0000

      Initialize target description early in IPA

I think that passing an index was probably a bad idea.

We used to pass the index, and then use that index to lookup which
target description to instantiate and use, the target description was
not generated until the index arrived.

However, the above commit fixed an issue where we can't call malloc()
within (certain parts of) the IPA (apparently), so instead we now
pre-compute _every_ possible target description within the IPA.  The
index is only used to lookup which of the (many) pre-computed target
descriptions to use.

It would (I think) have been easier all around if the IPA just
self-inspected, figured out its own xcr0 value, and used that to
create the one target description that is required.  So long as the
xcr0 to target description code is shared (at compile time) with
gdbserver, then we can be sure that the IPA will derive the same
target description as gdbserver, and we would avoid all this index
passing business, which has made this commit so very, very painful.

I did look at how a process might derive its own xcr0 value, but I
don't believe this is actually that simple, so for now I've just
doubled down on the index passing approach.

While reviewing earlier iterations of this patch there has been
discussion about the possibility of removing the IPA from GDB.  That
would certainly make all of the code touched in this patch much
simpler, but I don't really want to do that as part of this series.

** END OF AN ASIDE **

Currently then for x86/linux, gdbserver sends a number between 0 and 7
to the IPA, and the IPA uses this to create a target description.

However, I am proposing that gdbserver should now create one of (up
to) 64 different target descriptions for i386, so this 0 to 7 index
isn't going to be good enough any more (amd64 and x32 have slightly
fewer possible target descriptions, but still more than 8, so the
problem is the same).

For a while I wondered if I was going to have to try and find some
backward compatible solution for this mess.  But after seeing how
lightly the IPA is actually documented, I wonder if it is not the case
that there is a tight coupling between a version of gdbserver and a
version of the IPA?  At least I'm hoping so, and that's what I've
assumed in this commit.

In this commit I have thrown out the old IPA target description index
numbering scheme, and switched to a completely new numbering scheme.
Instead of the index that is passed being arbitrary, the index is
instead calculated from the set of xcr0 features that are present on
the target.  Within the IPA we can then reverse this logic to recreate
the xcr0 value based on the index, and from the xcr0 value we can
choose the correct target description.

With the gdbserver to IPA numbering scheme issue resolved I have then
update the gdbserver versions of amd64_linux_read_description and
i386_linux_read_description so that they cache target descriptions
using the same set of xcr0 features as GDB itself.

After this gdbserver should now always come up with the same target
description as GDB does on any x86/Linux target.

This commit does not introduce any new code sharing between GDB and
gdbserver as previous commits in this series have done.  Instead this
commit is all about bringing GDB and gdbserver into alignment
functionally so that the next commit(s) can merge the GDB and
gdbserver versions of these functions.

Notes On The Implementation
---------------------------

Previously, within gdbserver, target descriptions were cached within
arrays.  These arrays were sized based on enum x86_linux_tdesc and
xcr0_to_tdesc_idx returned the array (cache) index.

Now we need different array lengths for each of i386, amd64, and x32.
And the index to use within each array is calculated based on which
xcr0 bits are set and valid for a particular target type.

I really wanted to avoid having fixed array sizes, or having the set
of relevant xcr0 bits encoded in multiple places.

The solution I came up with was to create a single data structure
which would contain a list of xcr0 bits along with flags to indicate
which of the i386, amd64, and x32 targets the bit is relevant for.  By
making the table constexpr, and adding some constexpr helper
functions, it is possible to calculate the sizes for the cache arrays
at compile time, as well as the bit masks needed to each target type.

During review it was pointed out[1] that possibly the failure to check
the SSE and X87 bits for amd64/x32 targets might be an error, however,
if this is the case then this is an issue that existed long before
this patch.  I'd really like to keep this patch focused on reworking
the existing code and try to avoid changing how target descriptions
are actually created, mostly out of fear that I'll break something.

[1] https://inbox.sourceware.org/gdb-patches/MN2PR11MB4566070607318EE7E669A5E28E1B2@MN2PR11MB4566.namprd11.prod.outlook.com

Approved-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-06-14 09:08:45 +01:00
Andrew Burgess
bf616be991 gdb/gdbserver: share some code relating to target description creation
This commit is part of a series to share more of the x86 target
description creation code between GDB and gdbserver.

Unlike previous commits which were mostly refactoring, this commit is
the first that makes a real change, though that change should mostly
be for gdbserver; I've largely adopted the "GDB" way of doing things
for gdbserver, and this fixes a real gdbserver bug.

On a x86-64 Linux target, running the test:

  gdb.server/connect-with-no-symbol-file.exp

results in two core files being created.  Both of these core files are
from the inferior process, created after gdbserver has detached.

In this test a gdbserver process is started and then, after gdbserver
has started, but before GDB attaches, we either delete the inferior
executable, or change its permissions so it can't be read.  Only after
doing this do we attempt to connect with GDB.

As GDB connects to gdbserver, gdbserver attempts to figure out the
target description so that it can send the description to GDB, this
involves a call to x86_linux_read_description.

In x86_linux_read_description one of the first things we do is try to
figure out if the process is 32-bit or 64-bit.  To do this we look up
the executable via the thread-id, and then attempt to read the
architecture size from the executable.  This isn't going to work if
the executable has been deleted, or is no longer readable.

And so, as we can't read the executable, we default to an i386 target
and use an i386 target description.

A consequence of using an i386 target description is that addresses
are assumed to be 32-bits.  Here's an example session that shows the
problems this causes.  This is run on an x86-64 machine, and the test
binary (xx.x) is a standard 64-bit x86-64 binary:

  shell_1$ gdbserver --once localhost :54321 /tmp/xx.x

  shell_2$ gdb -q
  (gdb) set sysroot
  (gdb) shell chmod 000 /tmp/xx.x
  (gdb) target remote :54321
  Remote debugging using :54321
  warning: /tmp/xx.x: Permission denied.
  0xf7fd3110 in ?? ()
  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386").
  (gdb) p/x $pc
  $1 = 0xf7fd3110
  (gdb) info proc mappings
  process 2412639
  Mapped address spaces:

  	Start Addr   End Addr       Size     Offset  Perms   objfile
  	  0x400000   0x401000     0x1000        0x0  r--p   /tmp/xx.x
  	  0x401000   0x402000     0x1000     0x1000  r-xp   /tmp/xx.x
  	  0x402000   0x403000     0x1000     0x2000  r--p   /tmp/xx.x
  	  0x403000   0x405000     0x2000     0x2000  rw-p   /tmp/xx.x
  	0xf7fcb000 0xf7fcf000     0x4000        0x0  r--p   [vvar]
  	0xf7fcf000 0xf7fd1000     0x2000        0x0  r-xp   [vdso]
  	0xf7fd1000 0xf7fd3000     0x2000        0x0  r--p   /usr/lib64/ld-2.30.so
  	0xf7fd3000 0xf7ff3000    0x20000     0x2000  r-xp   /usr/lib64/ld-2.30.so
  	0xf7ff3000 0xf7ffb000     0x8000    0x22000  r--p   /usr/lib64/ld-2.30.so
  	0xf7ffc000 0xf7ffe000     0x2000    0x2a000  rw-p   /usr/lib64/ld-2.30.so
  	0xf7ffe000 0xf7fff000     0x1000        0x0  rw-p
  	0xfffda000 0xfffff000    0x25000        0x0  rw-p   [stack]
  	0xff600000 0xff601000     0x1000        0x0  r-xp   [vsyscall]
  (gdb) info inferiors
    Num  Description       Connection           Executable
  * 1    process 2412639   1 (remote :54321)
  (gdb) shell cat /proc/2412639/maps
  00400000-00401000 r--p 00000000 fd:03 45907133           /tmp/xx.x
  00401000-00402000 r-xp 00001000 fd:03 45907133           /tmp/xx.x
  00402000-00403000 r--p 00002000 fd:03 45907133           /tmp/xx.x
  00403000-00405000 rw-p 00002000 fd:03 45907133           /tmp/xx.x
  7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0          [vvar]
  7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0          [vdso]
  7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
  7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0          [stack]
  ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
  (gdb)

Notice the difference between the mappings reported via GDB and those
reported directly from the kernel via /proc/PID/maps, the addresses of
every mapping is clamped to 32-bits for GDB, while the kernel reports
real 64-bit addresses.

Notice also that the $pc value is a 32-bit value.  It appears to be
within one of the mappings reported by GDB, but is outside any of the
mappings reported from the kernel.

And this is where the problem arises.  When gdbserver detaches from
the inferior we pass the inferior the address from which it should
resume.  Due to the 32/64 bit confusion we tell the inferior to resume
from the 32-bit $pc value, which is not within any valid mapping, and
so, as soon as the inferior resumes, it segfaults.

If we look at how GDB (not gdbserver) figures out its target
description then we see an interesting difference.  GDB doesn't try to
read the executable.  Instead GDB uses ptrace to query the thread's
state, and uses this to figure out the if the thread is 32 or 64 bit.

If we update gdbserver to do it the "GDB" way then the above problem
is resolved, gdbserver now sees the process as 64-bit, and when we
detach from the inferior we give it the correct 64-bit address, and
the inferior no longer segfaults.

Now, I could just update the gdbserver code, but better, I think, to
share one copy of the code between GDB and gdbserver in gdb/nat/.
That is what this commit does.

The cores of x86_linux_read_description from gdbserver and
x86_linux_nat_target::read_description from GDB are moved into a new
file gdb/nat/x86-linux-tdesc.c and combined into a single function
x86_linux_tdesc_for_tid which is called from each location.

This new function does things mostly the GDB way, some changes are
needed to allow for the sharing; we now take some pointers for where
the shared code can cache the xcr0 and xsave layout values.

Another thing to note about this commit is how the functions
i386_linux_read_description and amd64_linux_read_description are
handled.  For now I've left these function as implemented separately
in GDB and gdbserver.  I've moved the declarations of these functions
into gdb/arch/{i386,amd64}-linux-tdesc.h, but the implementations are
left where they are.

A later commit in this series will make these functions shared too,
but doing this is not trivial, so I've left that for a separate
commit.  Merging the declarations as I've done here ensures that
everyone implements the function to the same API, and once these
functions are shared (in a later commit) we'll want a shared
declaration anyway.

Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
Acked-By: John Baldwin <jhb@FreeBSD.org>
2024-06-14 09:08:45 +01:00
Andrew Burgess
18d4886c00 gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory
The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is
running on a kernel that supports the GETFPXREGS ptrace request.

Currently this global is declared twice (once in GDB and once in
gdbserver), I think it makes sense to move this global into the nat/
directory, and have a single declaration and definition.

While moving this variable I have converted it to a tribool, as that
was what it really was, if even used the same numbering as the tribool
enum (-1, 0, 1).  Where have_ptrace_getfpxregs was used I have updated
in the obvious way.

However, while making this change I noticed what I think is a bug in
x86_linux_nat_target::read_description and x86_linux_read_description,
both of these functions can be called multiple times, but in both
cases we only end up calling i386_linux_read_description the first
time through in the event that PTRACE_GETFPXREGS is not supported.
This is because initially have_ptrace_getfpxregs will be
TRIBOOL_UNKNOWN, but after the ptrace call fails we set
have_ptrace_getfpxregs to TRIBOOL_FALSE.  The next time we attempt to
read the target description we'll skip the ptrace call, and so skip
the call to i386_linux_read_description.

I've not tried to address this preexisting bug in this commit, this is
purely a refactor, there should be no user visible changes after this
commit.  In later commits I'll merge the gdbserver and GDB code
together into the nat/ directory, and after that I'll try to address
this bug.

Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-06-14 09:08:45 +01:00
Andrew Burgess
3d5394c501 gdbserver/x86: move no-xml code earlier in x86_linux_read_description
This commit is part of a series that aims to share more of the x86
target description reading/generation code between GDB and gdbserver.

There are a huge number of similarities between the code in
gdbserver's x86_linux_read_description function and GDB's
x86_linux_nat_target::read_description function, and it is this
similarity that I plan, in a later commit, to share between GDB and
gdbserver.

However, one thing that is different in x86_linux_read_description is
the code inside the '!use_xml' block.  This is the code that handles
the case where gdbserver is not allowed to send an XML target
description back to GDB.  In this case gdbserver uses some predefined,
fixed, target descriptions.

First, it's worth noting that I suspect this code is not tested any
more.  I couldn't find anything in the testsuite that tries to disable
XML target description support.  And the idea of having a single
"fixed" target description really doesn't work well when we think
about all the various x86 extensions that exist.  Part of me would
like to rip out the no-xml support in gdbserver (at least for x86),
and if a GDB connects that doesn't support XML target descriptions,
gdbserver can just give an error and drop the connection.  GDB has
supported XML target descriptions for 16 years now, I think it would
be reasonable for our shipped gdbserver to drop support for the old
way of doing things.

Anyway.... this commit doesn't do that.

What I did notice was that, over time, the '!use_xml' block appears to
have "drifted" within the x86_linux_read_description function; it's
now not the first check we do.  Instead we make some ptrace calls and
return a target description generated based on the result of these
ptrace calls.  Surely it only makes sense to generate variable target
descriptions if we can send these back to GDB?

So in this commit I propose to move the '!use_xml' block earlier in
the x86_linux_read_description function.

The benefit of this is that this leaves the later half of
x86_linux_read_description much more similar to the GDB function
x86_linux_nat_target::read_description and sets us up for potentially
sharing code between GDB and gdbserver in a later commit.

Approved-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-06-14 09:08:44 +01:00
Andrew Burgess
8a29222b85 gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition
Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
gdbserver.

This commit moves the definition into gdbsupport/x86-xstate.h, which
allows the #define to be shared.

There should be no user visible changes after this commit.

Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-06-14 09:08:44 +01:00
Andrew Burgess
0c58b372e0 gdbserver: convert have_ptrace_getregset to a tribool
Convert the have_ptrace_getregset global within gdbserver to a
tribool.  This brings the flag into alignment with the corresponding
flag in GDB.

The gdbserver have_ptrace_getregset variable is already used as a
tribool, it just doesn't have the tribool type.

In a future commit I plan to share more code between GDB and
gdbserver, and having this variable be the same type in both code
bases will make the sharing much easier.

There should be no user visible changes after this commit.

Approved-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-05-07 16:26:43 +01:00
Simon Marchi
18d2988e5d gdb, gdbserver, gdbsupport: remove includes of early headers
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them.  Remove all the inclusions of these files I could find.  Update
the generation scripts where relevant.

Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26 21:13:22 -04:00
Andrew Burgess
56f703d39d Revert "gdbserver: convert have_ptrace_getregset to a tribool"
This reverts commit 5920765d75.
2024-03-26 18:53:31 +00:00
Andrew Burgess
59b198a616 Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description"
This reverts commit 0a7bb97ad2.
2024-03-26 18:53:05 +00:00
Andrew Burgess
f06daade43 Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition"
This reverts commit 7816b81e9b.
2024-03-26 18:52:51 +00:00
Andrew Burgess
49a7660fb5 Revert "gdb/gdbserver: share some code relating to target description creation"
This reverts commit cd9b374ffe.
2024-03-26 18:52:44 +00:00
Andrew Burgess
cba2791ca6 Revert "gdbserver: update target description creation for x86/linux"
This reverts commit 61bb321605.
2024-03-26 18:52:27 +00:00
Andrew Burgess
69324a74e3 Revert "gdb/gdbserver: share x86/linux tdesc caching"
This reverts commit 198ff6ff81.
2024-03-26 18:52:17 +00:00
Andrew Burgess
198ff6ff81 gdb/gdbserver: share x86/linux tdesc caching
This commit builds on the previous series of commits to share the
target description caching code between GDB and gdbserver for
x86/Linux targets.

The objective of this commit is to move the four functions (2 each of)
i386_linux_read_description and amd64_linux_read_description into
gdb/nat/x86-linux-tdesc.c and combine them so we have just a single
copy of each.  Then both GDB and gdbserver will link against these
shared functions.

It is worth reading the description of the previous commit to see why
this merging is not as simple as it seems: on the gdbserver side we
actually have two users of these functions, gdbserver itself, and the
in process agent (IPA).

However, the previous commit streamlined the gdbserver code, and so
now it is simple to move the two functions along with all their
support functions from the gdbserver directory into the gdb/nat/
directory, and then GDB is fine to call these functions.

One small curiosity with this patch is the function
x86_linux_post_init_tdesc.  On the gdbserver side the two functions
amd64_linux_read_description and i386_linux_read_description have some
functionality that is not present on the GDB side, that is some
additional configuration that is performed as each target description
is created to setup the expedited registers.

To support this I've added the function x86_linux_post_init_tdesc.
This function is called from the two *_linux_read_description
functions, but is implemented separately for GDB and gdbserver.

This does mean adding back some non-shared code when this whole series
has been about sharing code, but now the only non-shared bit is the
single line that is actually different between GDB and gdbserver, all
the rest, which is identical, is now shared.

I did need to add a new rule to the gdbserver Makefile, this is to
allow the nat/x86-linux-tdesc.c file to be compiled for the IPA.

Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-25 17:14:19 +00:00
Andrew Burgess
61bb321605 gdbserver: update target description creation for x86/linux
This commit is part of a series which aims to share more of the target
description creation between GDB and gdbserver for x86/Linux.

After some refactoring, the previous commit actually started to share
some code, we added the shared x86_linux_tdesc_for_tid function into
nat/x86-linux-tdesc.c.  However, this function still relies on
amd64_linux_read_description and i386_linux_read_description which are
implemented separately for both gdbserver and GDB.  Given that at
their core, all these functions to is:

  1. take an xcr0 value as input,
  2. mask out some feature bits,
  3. look for a cached pre-generated target description and return it
     if found,
  4. if no cached target description is found then call either
     amd64_create_target_description or
     i386_create_target_description to create a new target
     description, which is then added to the cache.  Return the newly
     created target description.

The inner functions amd64_create_target_description and
i386_create_target_description are already shared between GDB and
gdbserver (in the gdb/arch/ directory), so the only thing that
the *_read_description functions really do is add the caching layer,
and it feels like this really could be shared.

However, we have a small problem.

On the GDB side we create target descriptions using a different set of
cpu features than on the gdbserver side!  This means that for the
exact same target, we might get a different target description when
using native GDB vs using gdbserver.  This surely feels like a
mistake, I would expect to get the same target description on each.

The table below shows the number of possible different target
descriptions that we can create on the GDB side vs on the gdbserver
side for each target type:

        | GDB | gdbserver
  ------|-----|----------
  i386  | 64  | 7
  amd64 | 32  | 7
  x32   | 16  | 7

So in theory, all I want to do is move the GDB version
of *_read_description into the nat/ directory and have gdbserver use
that, then both GDB and gdbserver would be able to create any of the
possible target descriptions.

Unfortunately it's a little more complex than that due to the in
process agent (IPA).

When the IPA is in use, gdbserver sends a target description index to
the IPA, and the IPA uses this to find the correct target description
to use.

** START OF AN ASIDE **

Back in the day I suspect this approach made perfect sense.  However
since this commit:

  commit a880623024
  Date:   Thu Dec 7 17:07:01 2017 +0000

      Initialize target description early in IPA

I think passing the index is now more trouble than its worth.

We used to pass the index, and then use that index to lookup which
target description to instantiate and use.  However, the above commit
fixed an issue where we can't call malloc() within (certain parts of)
the IPA (apparently), so instead we now pre-compute _every_ possible
target description within the IPA.  The index is now only used to
lookup which of the (many) pre-computed target descriptions to use.

It would (I think) have been easier all around if the IPA just
self-inspected, figured out its own xcr0 value, and used that to
create the one target description that is required.  So long as the
xcr0 to target description code is shared (at compile time) with
gdbserver, then we can be sure that the IPA will derive the same
target description as gdbserver, and we would avoid all this index
passing business, which has made this commit so very, very painful.

** END OF AN ASIDE **

Currently then for x86/linux, gdbserver sends a number between 0 and 7
to the IPA, and the IPA uses this to create a target description.

However, I am proposing that gdbserver should now create one of (up
to) 64 different target descriptions for i386, so this 0 to 7 index
isn't going to be good enough any more (amd64 and x32 have slightly
fewer possible target descriptions, but still more than 8, so the
problem is the same).

For a while I wondered if I was going to have to try and find some
backward compatible solution for this mess.  But after seeing how
lightly the IPA is actually documented, I wonder if it is not the case
that there is a tight coupling between a version of gdbserver and a
version of the IPA?  At least I'm hoping so.

In this commit I have thrown out the old IPA target description index
numbering scheme, and switched to a completely new numbering scheme.
Instead of the index that is passed being arbitrary, the index is
instead calculated from the set of cpu features that are present on
the target.  Within the IPA we can then reverse this logic to recreate
the xcr0 value based on the index, and from the xcr0 value we can
create the correct target description.

With the gdbserver to IPA numbering scheme issue resolved I have then
update the gdbserver versions of amd64_linux_read_description and
i386_linux_read_description so that they create target descriptions
using the same set of cpu features as GDB itself.

After this gdbserver should now always come up with the same target
description as GDB does on any x86/Linux target.

This commit does not introduce any new code sharing between GDB and
gdbserver as previous commits in this series does.  Instead this
commit is all about bringing GDB and gdbserver into alignment
functionally so that the next commit can merge the GDB and gdbserver
versions of these functions.

Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-25 17:14:19 +00:00
Andrew Burgess
cd9b374ffe gdb/gdbserver: share some code relating to target description creation
This commit is part of a series to share more of the x86 target
description creation code between GDB and gdbserver.

Unlike previous commits which were mostly refactoring, this commit is
the first that makes a real change, though that change should mostly
be for gdbserver; I've largely adopted the "GDB" way of doing things
for gdbserver, and this fixes a real gdbserver bug.

On a x86-64 Linux target, running the test:

  gdb.server/connect-with-no-symbol-file.exp

results in two core files being created.  Both of these core files are
from the inferior process, created after gdbserver has detached.

In this test a gdbserver process is started and then, after gdbserver
has started, but before GDB attaches, we either delete the inferior
executable, or change its permissions so it can't be read.  Only after
doing this do we attempt to connect with GDB.

As GDB connects to gdbserver, gdbserver attempts to figure out the
target description so that it can send the description to GDB, this
involves a call to x86_linux_read_description.

In x86_linux_read_description one of the first things we do is try to
figure out if the process is 32-bit or 64-bit.  To do this we look up
the executable via the thread-id, and then attempt to read the
architecture size from the executable.  This isn't going to work if
the executable has been deleted, or is no longer readable.

And so, as we can't read the executable, we default to an i386 target
and use an i386 target description.

A consequence of using an i386 target description is that addresses
are assumed to be 32-bits.  Here's an example session that shows the
problems this causes.  This is run on an x86-64 machine, and the test
binary (xx.x) is a standard 64-bit x86-64 binary:

  shell_1$ gdbserver --once localhost :54321 /tmp/xx.x

  shell_2$ gdb -q
  (gdb) set sysroot
  (gdb) shell chmod 000 /tmp/xx.x
  (gdb) target remote :54321
  Remote debugging using :54321
  warning: /tmp/xx.x: Permission denied.
  0xf7fd3110 in ?? ()
  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386").
  (gdb) p/x $pc
  $1 = 0xf7fd3110
  (gdb) info proc mappings
  process 2412639
  Mapped address spaces:

  	Start Addr   End Addr       Size     Offset  Perms   objfile
  	  0x400000   0x401000     0x1000        0x0  r--p   /tmp/xx.x
  	  0x401000   0x402000     0x1000     0x1000  r-xp   /tmp/xx.x
  	  0x402000   0x403000     0x1000     0x2000  r--p   /tmp/xx.x
  	  0x403000   0x405000     0x2000     0x2000  rw-p   /tmp/xx.x
  	0xf7fcb000 0xf7fcf000     0x4000        0x0  r--p   [vvar]
  	0xf7fcf000 0xf7fd1000     0x2000        0x0  r-xp   [vdso]
  	0xf7fd1000 0xf7fd3000     0x2000        0x0  r--p   /usr/lib64/ld-2.30.so
  	0xf7fd3000 0xf7ff3000    0x20000     0x2000  r-xp   /usr/lib64/ld-2.30.so
  	0xf7ff3000 0xf7ffb000     0x8000    0x22000  r--p   /usr/lib64/ld-2.30.so
  	0xf7ffc000 0xf7ffe000     0x2000    0x2a000  rw-p   /usr/lib64/ld-2.30.so
  	0xf7ffe000 0xf7fff000     0x1000        0x0  rw-p
  	0xfffda000 0xfffff000    0x25000        0x0  rw-p   [stack]
  	0xff600000 0xff601000     0x1000        0x0  r-xp   [vsyscall]
  (gdb) info inferiors
    Num  Description       Connection           Executable
  * 1    process 2412639   1 (remote :54321)
  (gdb) shell cat /proc/2412639/maps
  00400000-00401000 r--p 00000000 fd:03 45907133           /tmp/xx.x
  00401000-00402000 r-xp 00001000 fd:03 45907133           /tmp/xx.x
  00402000-00403000 r--p 00002000 fd:03 45907133           /tmp/xx.x
  00403000-00405000 rw-p 00002000 fd:03 45907133           /tmp/xx.x
  7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0          [vvar]
  7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0          [vdso]
  7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904     /usr/lib64/ld-2.30.so
  7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
  7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0          [stack]
  ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]
  (gdb)

Notice the difference between the mappings reported via GDB and those
reported directly from the kernel via /proc/PID/maps, the addresses of
every mapping is clamped to 32-bits for GDB, while the kernel reports
real 64-bit addresses.

Notice also that the $pc value is a 32-bit value.  It appears to be
within one of the mappings reported by GDB, but is outside any of the
mappings reported from the kernel.

And this is where the problem arises.  When gdbserver detaches from
the inferior we pass the inferior the address from which it should
resume.  Due to the 32/64 bit confusion we tell the inferior to resume
from the 32-bit $pc value, which is not within any valid mapping, and
so, as soon as the inferior resumes, it segfaults.

If we look at how GDB (not gdbserver) figures out its target
description then we see an interesting difference.  GDB doesn't try to
read the executable.  Instead GDB uses ptrace to query the thread's
state, and uses this to figure out the if the thread is 32 or 64 bit.

If we update gdbserver to do it the "GDB" way then the above problem
is resolved, gdbserver now sees the process as 64-bit, and when we
detach from the inferior we give it the correct 64-bit address, and
the inferior no longer segfaults.

Now, I could just update the gdbserver code, but better, I think, to
share one copy of the code between GDB and gdbserver in gdb/nat/.
That is what this commit does.

The cores of x86_linux_read_description from gdbserver and
x86_linux_nat_target::read_description from GDB are moved into a new
file gdb/nat/x86-linux-tdesc.c and combined into a single function
x86_linux_tdesc_for_tid which is called from each location.

This new function does things the GDB way, the only changes are to
allow for the sharing; we now have a callback function to call the
first time that the xcr0 state is read, this allows for GDB and
gdbserver to perform their own initialisation as needed, and
additionally, the new function takes a pointer for where to cache the
xcr0 value, this isn't needed for this commit, but will be useful in a
later commit where gdbserver will want to read this cached xcr0
value.

Another thing to note about this commit is how the functions
i386_linux_read_description and amd64_linux_read_description are
handled.  For now I've left these function as implemented separately
in GDB and gdbserver.  I've moved the declarations of these functions
into gdb/nat/x86-linux-tdesc.h, but the implementations are left as
separate.

A later commit in this series will make these functions shared too,
but doing this is not trivial, so I've left that for a separate
commit.  Merging the declarations as I've done here ensures that
everyone implements the function to the same API, and once these
functions are shared (in a later commit) we'll want a shared
declaration anyway.

Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-25 17:14:19 +00:00
Andrew Burgess
7816b81e9b gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition
Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
gdbserver.

This commit is part of a series that aims to share more of the x86
target description creation code between GDB and gdbserver.  The
I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target
description creation, and I noticed that this constant is defined
separately for GDB and gdbserver.

This commit moves the definition into gdb/nat/x86-linux.h, which
allows the #define to be shared.

There should be no user visible changes after this commit.

Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-25 17:14:19 +00:00
Andrew Burgess
0a7bb97ad2 gdbserver/x86: move no-xml code earlier in x86_linux_read_description
This commit is part of a series that aims to share more of the x86
target description reading/generation code between GDB and gdbserver.

There are a huge number of similarities between the code in
gdbserver's x86_linux_read_description function and GDB's
x86_linux_nat_target::read_description function, and it is this
similarity that I plan, in a later commit, to share between GDB and
gdbserver.

However, one thing that is different in x86_linux_read_description is
the code inside the '!use_xml' block.  This is the code that handles
the case where gdbserver is not allowed to send an XML target
description back to GDB.  In this case gdbserver uses some predefined,
fixed, target descriptions.

First, it's worth noting that I suspect this code is not tested any
more.  I couldn't find anything in the testsuite that tries to disable
XML target description support.  And the idea of having a single
"fixed" target description really doesn't work well when we think
about all the various x86 extensions that exist.  Part of me would
like to rip out the no-xml support in gdbserver (at least for x86),
and if a GDB connects that doesn't support XML target descriptions,
gdbserver can just give an error and drop the connection.  GDB has
supported XML target descriptions for 16 years now, I think it would
be reasonable for our shipped gdbserver to drop support for the old
way of doing things.

Anyway.... this commit doesn't do that.

What I did notice was that, over time, the '!use_xml' block appears to
have "drifted" within the x86_linux_read_description function; it's
now not the first check we do.  Instead we make some ptrace calls and
return a target description generated based on the result of these
ptrace calls.  Surely it only makes sense to generate variable target
descriptions if we can send these back to GDB?

So in this commit I propose to move the '!use_xml' block earlier in
the x86_linux_read_description function.

The benefit of this is that this leaves the later half of
x86_linux_read_description much more similar to the GDB function
x86_linux_nat_target::read_description and sets us up for potentially
sharing code between GDB and gdbserver in a later commit.

Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-25 17:14:18 +00:00
Andrew Burgess
5920765d75 gdbserver: convert have_ptrace_getregset to a tribool
Convert the have_ptrace_getregset global within gdbserver to a
tribool.  This brings the flag into alignment with the corresponding
flag in GDB.

The gdbserver have_ptrace_getregset variable is already used as a
tribool, it just doesn't have the tribool type.

In a future commit I plan to share more code between GDB and
gdbserver, and having this variable be the same type in both code
bases will make the sharing much easier.

There should be no user visible changes after this commit.

Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-25 17:14:18 +00:00
H.J. Lu
4bb20a6244 gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32
Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits
on x32.

	PR server/31511
	* linux-x86-low.cc (x86_linux_read_description): Clear
	X86_XSTATE_MPX bits in xcr0 on x32.
Reviewed-by: Felix Willgerodt <felix.willgerodt@intel.com>
2024-03-21 12:44:40 -07:00
Andrew Burgess
1d506c26d9 Update copyright year range in header of all files managed by GDB
This commit is the result of the following actions:

  - Running gdb/copyright.py to update all of the copyright headers to
    include 2024,

  - Manually updating a few files the copyright.py script told me to
    update, these files had copyright headers embedded within the
    file,

  - Regenerating gdbsupport/Makefile.in to refresh it's copyright
    date,

  - Using grep to find other files that still mentioned 2023.  If
    these files were updated last year from 2022 to 2023 then I've
    updated them this year to 2024.

I'm sure I've probably missed some dates.  Feel free to fix them up as
you spot them.
2024-01-12 15:49:57 +00:00
John Baldwin
03e6fe7e0a gdbserver: Add a function to set the XSAVE mask and size.
Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set
the value instead.  Add a static global instance of x86_xsave_layout
and initialize it in the new function as well to be used in a future
commit to parse XSAVE extended state regions.

Update the Linux port to use this function rather than setting
x86_xcr0 directly.  In the case that XML is not supported, don't
bother setting x86_xcr0 to the default value but just omit the call to
i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for
non-XML.

In addition, use x86_xsave_length to determine the size of the XSAVE
register set via CPUID.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-28 14:18:19 -07:00
Joel Brobecker
213516ef31 Update copyright year range in header of all files managed by GDB
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
2023-01-01 17:01:16 +04:00
Simon Marchi
5e219e0f46 gdbserver/linux-x86: move lwp declaration out of __x86_64__ region
Commit 4855cbdc3d ("gdbserver/linux-x86: make is_64bit_tdesc accept
thread as a parameter") caused this when building in 32 bits / i386
mode:

      CXX    linux-x86-low.o
    In file included from /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:24:
    /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc: In member function ‘virtual int x86_target::low_get_thread_area(int, CORE_ADDR*)’:
    /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:357:47: error: ‘lwp’ was not declared in this scope
      357 |     struct thread_info *thr = get_lwp_thread (lwp);
          |                                               ^~~
    /home/smarchi/src/binutils-gdb/gdbserver/linux-low.h:709:31: note: in definition of macro ‘get_lwp_thread’
      709 | #define get_lwp_thread(lwp) ((lwp)->thread)
          |                               ^~~

This is because it moved the lwp variable declaration inside the
__x86_64__ guard, making it unavailable when building in 32 bits mode.
Move the lwp variable outside of the __x86_64__ region.

Change-Id: I7fa3938c6b44b345c27a52c8b8d3ea12aba53e05
2022-11-18 12:18:53 -05:00
Simon Marchi
4855cbdc3d gdbserver/linux-x86: make is_64bit_tdesc accept thread as a parameter
ps_get_thread_area receives as a parameter the lwpid it must work on.
It then calls is_64bit_tdesc, which uses the current_thread as the
thread to work on.  However, it is not said that both are the same.

This became a problem when working in a following patch that makes
find_one_thread switch to a process but to no thread (current_thread ==
nullptr).  When libthread_db needed to get the thread area,
is_64bit_tdesc would try to get the regcache of a nullptr thread.

Fix that by making is_64bit_tdesc accept the thread to work on as a
parameter.  Find the right thread from the context, when possible (when
we know the lwpid to work on).  Otherwise, pass "current_thread", to
retain the existing behavior.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I44394d6be92392fa28de71982fd04517ce8a3007
2022-11-18 11:11:42 -05:00
Simon Marchi
c058728c31 gdbserver: introduce threads_debug_printf, THREADS_SCOPED_DEBUG_ENTER_EXIT
Add the threads_debug_printf and THREADS_SCOPED_DEBUG_ENTER_EXIT, which
use the logging infrastructure from gdbsupport/common-debug.h.  Replace
all debug_print uses that are predicated by debug_threads with
threads_dethreads_debug_printf.  Replace uses of the debug_enter and
debug_exit macros with THREADS_SCOPED_DEBUG_ENTER_EXIT, which serves
essentially the same purpose, but allows showing what comes between the
enter and the exit in an indented form.

Note that "threads" debug is currently used for a bit of everything in
GDBserver, not only threads related stuff.  It should ideally be cleaned
up and separated logically as is done in GDB, but that's out of the
scope of this patch.

Change-Id: I2d4546464462cb4c16f7f1168c5cec5a89f2289a
2022-01-18 13:44:32 -05:00
Joel Brobecker
4a94e36819 Automatic Copyright Year update after running gdb/copyright.py
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.

For the avoidance of doubt, all changes in this commits were
performed by the script.
2022-01-01 19:13:23 +04:00
Tankut Baris Aktemur
24583e45ef gdbserver: replace direct assignments to current_thread
Replace the direct assignments to current_thread with
switch_to_thread.  Use scoped_restore_current_thread when appropriate.
There is one instance remaining in linux-low.cc's wait_for_sigstop.
This will be handled in a separate patch.

Regression-tested on X86-64 Linux using the native-gdbserver and
native-extended-gdbserver board files.
2021-12-13 12:22:48 +01:00
Simon Marchi
6bd434d6ca gdb: make some variables static
I'm trying to enable clang's -Wmissing-variable-declarations warning.
This patch fixes all the obvious spots where we can simply add "static"
(at least, found when building on x86-64 Linux).

gdb/ChangeLog:

	* aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static.
	* aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind,
	aarch64_stub_unwind, aarch64_normal_base, ): Make static.
	* arm-linux-tdep.c (arm_prologue_unwind): Make static.
	* arm-tdep.c (struct frame_unwind): Make static.
	* auto-load.c (auto_load_safe_path_vec): Make static.
	* csky-tdep.c (csky_stub_unwind): Make static.
	* gdbarch.c (gdbarch_data_registry): Make static.
	* gnu-v2-abi.c (gnu_v2_abi_ops): Make static.
	* i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static.
	* i386-tdep.c (i386_frame_setup_skip_insns,
	i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns):
	Make static.
	* infrun.c (observer_mode): Make static.
	* linux-nat.c (sigchld_action): Make static.
	* linux-thread-db.c (thread_db_list): Make static.
	* maint-test-options.c (maintenance_test_options_list):
	* mep-tdep.c (mep_csr_registers): Make static.
	* mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name.
	(stats): Make static.
	* nat/linux-osdata.c (struct osdata_type): Make static.
	* ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static.
	* progspace.c (last_program_space_num): Make static.
	* python/py-param.c (struct parm_constant): Remove struct type
	name.
	(parm_constants): Make static.
	* python/py-record-btrace.c (btpy_list_methods): Make static.
	* python/py-record.c (recpy_gap_type): Make static.
	* record.c (record_goto_cmdlist): Make static.
	* regcache.c (regcache_descr_handle): Make static.
	* registry.h (DEFINE_REGISTRY): Make definition static.
	* symmisc.c (std_in, std_out, std_err): Make static.
	* top.c (previous_saved_command_line): Make static.
	* tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make
	static.
	* unittests/command-def-selftests.c (nr_duplicates,
	nr_invalid_prefixcmd, lists): Make static.
	* unittests/observable-selftests.c (test_notification): Make
	static.
	* unittests/optional/assignment/1.cc (counter): Make static.
	* unittests/optional/assignment/2.cc (counter): Make static.
	* unittests/optional/assignment/3.cc (counter): Make static.
	* unittests/optional/assignment/4.cc (counter): Make static.
	* unittests/optional/assignment/5.cc (counter): Make static.
	* unittests/optional/assignment/6.cc (counter): Make static.

gdbserver/ChangeLog:

	* ax.cc (bytecode_address_table): Make static.
	* debug.cc (debug_file): Make static.
	* linux-low.cc (stopping_threads): Make static.
	(step_over_bkpt): Make static.
	* linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static.
	* tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt,
	alloced_trace_state_variables, trace_buffer_ctrl,
	tracing_start_time, tracing_stop_time, tracing_user_name,
	tracing_notes, tracing_stop_note): Make static.

Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
2021-01-20 20:55:05 -05:00
Tom de Vries
037e8112b9 [gdb/server] Don't overwrite fs/gs_base with -m32
Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...

When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...

The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS.  After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.

Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.

The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f55 "Fix gdbserver qGetTLSAddr for
x86_64 -m32".  The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument.  But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.

Fix the segfault by redoing the fix from commit 9e0aa64f55 in minimal form.

Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
  - native
  - gdbserver -m32
  - -m32
- openSUSE Factory (using kernel version 5.10.5):
  - native
  - m32

gdbserver/ChangeLog:

2021-01-20  Tom de Vries  <tdevries@suse.de>

	* linux-x86-low.cc (collect_register_i386): New function.
	(x86_fill_gregset):  Remove memset.  Use collect_register_i386.
2021-01-20 16:29:30 +01:00
Joel Brobecker
3666a04883 Update copyright year range in all GDB files
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...

gdb/ChangeLog

        Update copyright year range in copyright header of all GDB files.
2021-01-01 12:12:21 +04:00
Simon Marchi
dda83cd783 gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c).  I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it?  What if the lines around it are also
wrong, do I fix them too?  I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.

So I propose to fix as much as possible once and for all (hopefully).

One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines.  My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for.  So you
already need a somewhat efficient way to do this.

Using some interactive tool, rather than plain git-blame, makes this
trivial.  For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too.  My point is that it won't
really make archeology more difficult.

The other typical counter argument is that it will cause conflicts with
existing patches.  That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve.  I have also tried "git
rebase --ignore-whitespace", it seems to work well.  Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).

gdb/ChangeLog:

	* aarch64-linux-tdep.c: Fix indentation.
	* aarch64-ravenscar-thread.c: Fix indentation.
	* aarch64-tdep.c: Fix indentation.
	* aarch64-tdep.h: Fix indentation.
	* ada-lang.c: Fix indentation.
	* ada-lang.h: Fix indentation.
	* ada-tasks.c: Fix indentation.
	* ada-typeprint.c: Fix indentation.
	* ada-valprint.c: Fix indentation.
	* ada-varobj.c: Fix indentation.
	* addrmap.c: Fix indentation.
	* addrmap.h: Fix indentation.
	* agent.c: Fix indentation.
	* aix-thread.c: Fix indentation.
	* alpha-bsd-nat.c: Fix indentation.
	* alpha-linux-tdep.c: Fix indentation.
	* alpha-mdebug-tdep.c: Fix indentation.
	* alpha-nbsd-tdep.c: Fix indentation.
	* alpha-obsd-tdep.c: Fix indentation.
	* alpha-tdep.c: Fix indentation.
	* amd64-bsd-nat.c: Fix indentation.
	* amd64-darwin-tdep.c: Fix indentation.
	* amd64-linux-nat.c: Fix indentation.
	* amd64-linux-tdep.c: Fix indentation.
	* amd64-nat.c: Fix indentation.
	* amd64-obsd-tdep.c: Fix indentation.
	* amd64-tdep.c: Fix indentation.
	* amd64-windows-tdep.c: Fix indentation.
	* annotate.c: Fix indentation.
	* arc-tdep.c: Fix indentation.
	* arch-utils.c: Fix indentation.
	* arch/arm-get-next-pcs.c: Fix indentation.
	* arch/arm.c: Fix indentation.
	* arm-linux-nat.c: Fix indentation.
	* arm-linux-tdep.c: Fix indentation.
	* arm-nbsd-tdep.c: Fix indentation.
	* arm-pikeos-tdep.c: Fix indentation.
	* arm-tdep.c: Fix indentation.
	* arm-tdep.h: Fix indentation.
	* arm-wince-tdep.c: Fix indentation.
	* auto-load.c: Fix indentation.
	* auxv.c: Fix indentation.
	* avr-tdep.c: Fix indentation.
	* ax-gdb.c: Fix indentation.
	* ax-general.c: Fix indentation.
	* bfin-linux-tdep.c: Fix indentation.
	* block.c: Fix indentation.
	* block.h: Fix indentation.
	* blockframe.c: Fix indentation.
	* bpf-tdep.c: Fix indentation.
	* break-catch-sig.c: Fix indentation.
	* break-catch-syscall.c: Fix indentation.
	* break-catch-throw.c: Fix indentation.
	* breakpoint.c: Fix indentation.
	* breakpoint.h: Fix indentation.
	* bsd-uthread.c: Fix indentation.
	* btrace.c: Fix indentation.
	* build-id.c: Fix indentation.
	* buildsym-legacy.h: Fix indentation.
	* buildsym.c: Fix indentation.
	* c-typeprint.c: Fix indentation.
	* c-valprint.c: Fix indentation.
	* c-varobj.c: Fix indentation.
	* charset.c: Fix indentation.
	* cli/cli-cmds.c: Fix indentation.
	* cli/cli-decode.c: Fix indentation.
	* cli/cli-decode.h: Fix indentation.
	* cli/cli-script.c: Fix indentation.
	* cli/cli-setshow.c: Fix indentation.
	* coff-pe-read.c: Fix indentation.
	* coffread.c: Fix indentation.
	* compile/compile-cplus-types.c: Fix indentation.
	* compile/compile-object-load.c: Fix indentation.
	* compile/compile-object-run.c: Fix indentation.
	* completer.c: Fix indentation.
	* corefile.c: Fix indentation.
	* corelow.c: Fix indentation.
	* cp-abi.h: Fix indentation.
	* cp-namespace.c: Fix indentation.
	* cp-support.c: Fix indentation.
	* cp-valprint.c: Fix indentation.
	* cris-linux-tdep.c: Fix indentation.
	* cris-tdep.c: Fix indentation.
	* darwin-nat-info.c: Fix indentation.
	* darwin-nat.c: Fix indentation.
	* darwin-nat.h: Fix indentation.
	* dbxread.c: Fix indentation.
	* dcache.c: Fix indentation.
	* disasm.c: Fix indentation.
	* dtrace-probe.c: Fix indentation.
	* dwarf2/abbrev.c: Fix indentation.
	* dwarf2/attribute.c: Fix indentation.
	* dwarf2/expr.c: Fix indentation.
	* dwarf2/frame.c: Fix indentation.
	* dwarf2/index-cache.c: Fix indentation.
	* dwarf2/index-write.c: Fix indentation.
	* dwarf2/line-header.c: Fix indentation.
	* dwarf2/loc.c: Fix indentation.
	* dwarf2/macro.c: Fix indentation.
	* dwarf2/read.c: Fix indentation.
	* dwarf2/read.h: Fix indentation.
	* elfread.c: Fix indentation.
	* eval.c: Fix indentation.
	* event-top.c: Fix indentation.
	* exec.c: Fix indentation.
	* exec.h: Fix indentation.
	* expprint.c: Fix indentation.
	* f-lang.c: Fix indentation.
	* f-typeprint.c: Fix indentation.
	* f-valprint.c: Fix indentation.
	* fbsd-nat.c: Fix indentation.
	* fbsd-tdep.c: Fix indentation.
	* findvar.c: Fix indentation.
	* fork-child.c: Fix indentation.
	* frame-unwind.c: Fix indentation.
	* frame-unwind.h: Fix indentation.
	* frame.c: Fix indentation.
	* frv-linux-tdep.c: Fix indentation.
	* frv-tdep.c: Fix indentation.
	* frv-tdep.h: Fix indentation.
	* ft32-tdep.c: Fix indentation.
	* gcore.c: Fix indentation.
	* gdb_bfd.c: Fix indentation.
	* gdbarch.sh: Fix indentation.
	* gdbarch.c: Re-generate
	* gdbarch.h: Re-generate.
	* gdbcore.h: Fix indentation.
	* gdbthread.h: Fix indentation.
	* gdbtypes.c: Fix indentation.
	* gdbtypes.h: Fix indentation.
	* glibc-tdep.c: Fix indentation.
	* gnu-nat.c: Fix indentation.
	* gnu-nat.h: Fix indentation.
	* gnu-v2-abi.c: Fix indentation.
	* gnu-v3-abi.c: Fix indentation.
	* go32-nat.c: Fix indentation.
	* guile/guile-internal.h: Fix indentation.
	* guile/scm-cmd.c: Fix indentation.
	* guile/scm-frame.c: Fix indentation.
	* guile/scm-iterator.c: Fix indentation.
	* guile/scm-math.c: Fix indentation.
	* guile/scm-ports.c: Fix indentation.
	* guile/scm-pretty-print.c: Fix indentation.
	* guile/scm-value.c: Fix indentation.
	* h8300-tdep.c: Fix indentation.
	* hppa-linux-nat.c: Fix indentation.
	* hppa-linux-tdep.c: Fix indentation.
	* hppa-nbsd-nat.c: Fix indentation.
	* hppa-nbsd-tdep.c: Fix indentation.
	* hppa-obsd-nat.c: Fix indentation.
	* hppa-tdep.c: Fix indentation.
	* hppa-tdep.h: Fix indentation.
	* i386-bsd-nat.c: Fix indentation.
	* i386-darwin-nat.c: Fix indentation.
	* i386-darwin-tdep.c: Fix indentation.
	* i386-dicos-tdep.c: Fix indentation.
	* i386-gnu-nat.c: Fix indentation.
	* i386-linux-nat.c: Fix indentation.
	* i386-linux-tdep.c: Fix indentation.
	* i386-nto-tdep.c: Fix indentation.
	* i386-obsd-tdep.c: Fix indentation.
	* i386-sol2-nat.c: Fix indentation.
	* i386-tdep.c: Fix indentation.
	* i386-tdep.h: Fix indentation.
	* i386-windows-tdep.c: Fix indentation.
	* i387-tdep.c: Fix indentation.
	* i387-tdep.h: Fix indentation.
	* ia64-libunwind-tdep.c: Fix indentation.
	* ia64-libunwind-tdep.h: Fix indentation.
	* ia64-linux-nat.c: Fix indentation.
	* ia64-linux-tdep.c: Fix indentation.
	* ia64-tdep.c: Fix indentation.
	* ia64-tdep.h: Fix indentation.
	* ia64-vms-tdep.c: Fix indentation.
	* infcall.c: Fix indentation.
	* infcmd.c: Fix indentation.
	* inferior.c: Fix indentation.
	* infrun.c: Fix indentation.
	* iq2000-tdep.c: Fix indentation.
	* language.c: Fix indentation.
	* linespec.c: Fix indentation.
	* linux-fork.c: Fix indentation.
	* linux-nat.c: Fix indentation.
	* linux-tdep.c: Fix indentation.
	* linux-thread-db.c: Fix indentation.
	* lm32-tdep.c: Fix indentation.
	* m2-lang.c: Fix indentation.
	* m2-typeprint.c: Fix indentation.
	* m2-valprint.c: Fix indentation.
	* m32c-tdep.c: Fix indentation.
	* m32r-linux-tdep.c: Fix indentation.
	* m32r-tdep.c: Fix indentation.
	* m68hc11-tdep.c: Fix indentation.
	* m68k-bsd-nat.c: Fix indentation.
	* m68k-linux-nat.c: Fix indentation.
	* m68k-linux-tdep.c: Fix indentation.
	* m68k-tdep.c: Fix indentation.
	* machoread.c: Fix indentation.
	* macrocmd.c: Fix indentation.
	* macroexp.c: Fix indentation.
	* macroscope.c: Fix indentation.
	* macrotab.c: Fix indentation.
	* macrotab.h: Fix indentation.
	* main.c: Fix indentation.
	* mdebugread.c: Fix indentation.
	* mep-tdep.c: Fix indentation.
	* mi/mi-cmd-catch.c: Fix indentation.
	* mi/mi-cmd-disas.c: Fix indentation.
	* mi/mi-cmd-env.c: Fix indentation.
	* mi/mi-cmd-stack.c: Fix indentation.
	* mi/mi-cmd-var.c: Fix indentation.
	* mi/mi-cmds.c: Fix indentation.
	* mi/mi-main.c: Fix indentation.
	* mi/mi-parse.c: Fix indentation.
	* microblaze-tdep.c: Fix indentation.
	* minidebug.c: Fix indentation.
	* minsyms.c: Fix indentation.
	* mips-linux-nat.c: Fix indentation.
	* mips-linux-tdep.c: Fix indentation.
	* mips-nbsd-tdep.c: Fix indentation.
	* mips-tdep.c: Fix indentation.
	* mn10300-linux-tdep.c: Fix indentation.
	* mn10300-tdep.c: Fix indentation.
	* moxie-tdep.c: Fix indentation.
	* msp430-tdep.c: Fix indentation.
	* namespace.h: Fix indentation.
	* nat/fork-inferior.c: Fix indentation.
	* nat/gdb_ptrace.h: Fix indentation.
	* nat/linux-namespaces.c: Fix indentation.
	* nat/linux-osdata.c: Fix indentation.
	* nat/netbsd-nat.c: Fix indentation.
	* nat/x86-dregs.c: Fix indentation.
	* nbsd-nat.c: Fix indentation.
	* nbsd-tdep.c: Fix indentation.
	* nios2-linux-tdep.c: Fix indentation.
	* nios2-tdep.c: Fix indentation.
	* nto-procfs.c: Fix indentation.
	* nto-tdep.c: Fix indentation.
	* objfiles.c: Fix indentation.
	* objfiles.h: Fix indentation.
	* opencl-lang.c: Fix indentation.
	* or1k-tdep.c: Fix indentation.
	* osabi.c: Fix indentation.
	* osabi.h: Fix indentation.
	* osdata.c: Fix indentation.
	* p-lang.c: Fix indentation.
	* p-typeprint.c: Fix indentation.
	* p-valprint.c: Fix indentation.
	* parse.c: Fix indentation.
	* ppc-linux-nat.c: Fix indentation.
	* ppc-linux-tdep.c: Fix indentation.
	* ppc-nbsd-nat.c: Fix indentation.
	* ppc-nbsd-tdep.c: Fix indentation.
	* ppc-obsd-nat.c: Fix indentation.
	* ppc-ravenscar-thread.c: Fix indentation.
	* ppc-sysv-tdep.c: Fix indentation.
	* ppc64-tdep.c: Fix indentation.
	* printcmd.c: Fix indentation.
	* proc-api.c: Fix indentation.
	* producer.c: Fix indentation.
	* producer.h: Fix indentation.
	* prologue-value.c: Fix indentation.
	* prologue-value.h: Fix indentation.
	* psymtab.c: Fix indentation.
	* python/py-arch.c: Fix indentation.
	* python/py-bpevent.c: Fix indentation.
	* python/py-event.c: Fix indentation.
	* python/py-event.h: Fix indentation.
	* python/py-finishbreakpoint.c: Fix indentation.
	* python/py-frame.c: Fix indentation.
	* python/py-framefilter.c: Fix indentation.
	* python/py-inferior.c: Fix indentation.
	* python/py-infthread.c: Fix indentation.
	* python/py-objfile.c: Fix indentation.
	* python/py-prettyprint.c: Fix indentation.
	* python/py-registers.c: Fix indentation.
	* python/py-signalevent.c: Fix indentation.
	* python/py-stopevent.c: Fix indentation.
	* python/py-stopevent.h: Fix indentation.
	* python/py-threadevent.c: Fix indentation.
	* python/py-tui.c: Fix indentation.
	* python/py-unwind.c: Fix indentation.
	* python/py-value.c: Fix indentation.
	* python/py-xmethods.c: Fix indentation.
	* python/python-internal.h: Fix indentation.
	* python/python.c: Fix indentation.
	* ravenscar-thread.c: Fix indentation.
	* record-btrace.c: Fix indentation.
	* record-full.c: Fix indentation.
	* record.c: Fix indentation.
	* reggroups.c: Fix indentation.
	* regset.h: Fix indentation.
	* remote-fileio.c: Fix indentation.
	* remote.c: Fix indentation.
	* reverse.c: Fix indentation.
	* riscv-linux-tdep.c: Fix indentation.
	* riscv-ravenscar-thread.c: Fix indentation.
	* riscv-tdep.c: Fix indentation.
	* rl78-tdep.c: Fix indentation.
	* rs6000-aix-tdep.c: Fix indentation.
	* rs6000-lynx178-tdep.c: Fix indentation.
	* rs6000-nat.c: Fix indentation.
	* rs6000-tdep.c: Fix indentation.
	* rust-lang.c: Fix indentation.
	* rx-tdep.c: Fix indentation.
	* s12z-tdep.c: Fix indentation.
	* s390-linux-tdep.c: Fix indentation.
	* score-tdep.c: Fix indentation.
	* ser-base.c: Fix indentation.
	* ser-mingw.c: Fix indentation.
	* ser-uds.c: Fix indentation.
	* ser-unix.c: Fix indentation.
	* serial.c: Fix indentation.
	* sh-linux-tdep.c: Fix indentation.
	* sh-nbsd-tdep.c: Fix indentation.
	* sh-tdep.c: Fix indentation.
	* skip.c: Fix indentation.
	* sol-thread.c: Fix indentation.
	* solib-aix.c: Fix indentation.
	* solib-darwin.c: Fix indentation.
	* solib-frv.c: Fix indentation.
	* solib-svr4.c: Fix indentation.
	* solib.c: Fix indentation.
	* source.c: Fix indentation.
	* sparc-linux-tdep.c: Fix indentation.
	* sparc-nbsd-tdep.c: Fix indentation.
	* sparc-obsd-tdep.c: Fix indentation.
	* sparc-ravenscar-thread.c: Fix indentation.
	* sparc-tdep.c: Fix indentation.
	* sparc64-linux-tdep.c: Fix indentation.
	* sparc64-nbsd-tdep.c: Fix indentation.
	* sparc64-obsd-tdep.c: Fix indentation.
	* sparc64-tdep.c: Fix indentation.
	* stabsread.c: Fix indentation.
	* stack.c: Fix indentation.
	* stap-probe.c: Fix indentation.
	* stubs/ia64vms-stub.c: Fix indentation.
	* stubs/m32r-stub.c: Fix indentation.
	* stubs/m68k-stub.c: Fix indentation.
	* stubs/sh-stub.c: Fix indentation.
	* stubs/sparc-stub.c: Fix indentation.
	* symfile-mem.c: Fix indentation.
	* symfile.c: Fix indentation.
	* symfile.h: Fix indentation.
	* symmisc.c: Fix indentation.
	* symtab.c: Fix indentation.
	* symtab.h: Fix indentation.
	* target-float.c: Fix indentation.
	* target.c: Fix indentation.
	* target.h: Fix indentation.
	* tic6x-tdep.c: Fix indentation.
	* tilegx-linux-tdep.c: Fix indentation.
	* tilegx-tdep.c: Fix indentation.
	* top.c: Fix indentation.
	* tracefile-tfile.c: Fix indentation.
	* tracepoint.c: Fix indentation.
	* tui/tui-disasm.c: Fix indentation.
	* tui/tui-io.c: Fix indentation.
	* tui/tui-regs.c: Fix indentation.
	* tui/tui-stack.c: Fix indentation.
	* tui/tui-win.c: Fix indentation.
	* tui/tui-winsource.c: Fix indentation.
	* tui/tui.c: Fix indentation.
	* typeprint.c: Fix indentation.
	* ui-out.h: Fix indentation.
	* unittests/copy_bitwise-selftests.c: Fix indentation.
	* unittests/memory-map-selftests.c: Fix indentation.
	* utils.c: Fix indentation.
	* v850-tdep.c: Fix indentation.
	* valarith.c: Fix indentation.
	* valops.c: Fix indentation.
	* valprint.c: Fix indentation.
	* valprint.h: Fix indentation.
	* value.c: Fix indentation.
	* value.h: Fix indentation.
	* varobj.c: Fix indentation.
	* vax-tdep.c: Fix indentation.
	* windows-nat.c: Fix indentation.
	* windows-tdep.c: Fix indentation.
	* xcoffread.c: Fix indentation.
	* xml-syscall.c: Fix indentation.
	* xml-tdesc.c: Fix indentation.
	* xstormy16-tdep.c: Fix indentation.
	* xtensa-config.c: Fix indentation.
	* xtensa-linux-nat.c: Fix indentation.
	* xtensa-linux-tdep.c: Fix indentation.
	* xtensa-tdep.c: Fix indentation.

gdbserver/ChangeLog:

	* ax.cc: Fix indentation.
	* dll.cc: Fix indentation.
	* inferiors.h: Fix indentation.
	* linux-low.cc: Fix indentation.
	* linux-nios2-low.cc: Fix indentation.
	* linux-ppc-ipa.cc: Fix indentation.
	* linux-ppc-low.cc: Fix indentation.
	* linux-x86-low.cc: Fix indentation.
	* linux-xtensa-low.cc: Fix indentation.
	* regcache.cc: Fix indentation.
	* server.cc: Fix indentation.
	* tracepoint.cc: Fix indentation.

gdbsupport/ChangeLog:

	* common-exceptions.h: Fix indentation.
	* event-loop.cc: Fix indentation.
	* fileio.cc: Fix indentation.
	* filestuff.cc: Fix indentation.
	* gdb-dlfcn.cc: Fix indentation.
	* gdb_string_view.h: Fix indentation.
	* job-control.cc: Fix indentation.
	* signals.cc: Fix indentation.

Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-11-02 10:28:45 -05:00
Andrew Burgess
51a948fdf0 gdb: Have allocate_target_description return a unique_ptr
Update allocate_target_description to return a target_desc_up, a
specialisation of unique_ptr.

This commit does not attempt to make use of the unique_ptr in the
best possible way, in almost all cases we immediately release the
pointer from within the unique_ptr and then continue as before.

There are a few places where it was easy to handle the unique_ptr, and
in these cases I've done that.

Everything under gdb/features/* is auto-regenerated.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* arch/aarch32.c (aarch32_create_target_description): Release
	unique_ptr returned from allocate_target_description.
	* arch/aarch64.c (aarch64_create_target_description): Likewise.
	* arch/amd64.c (amd64_create_target_description): Likewise.
	* arch/arc.c (arc_create_target_description): Likewise.
	* arch/arm.c (arm_create_target_description): Likewise.
	* arch/i386.c (i386_create_target_description): Likewise.
	* arch/riscv.c (riscv_create_target_description): Update return
	type.  Handle allocate_target_description returning a unique_ptr.
	(riscv_lookup_target_description): Update to handle unique_ptr.
	* arch/tic6x.c (tic6x_create_target_description): Release
	unique_ptr returned from allocate_target_description.
	* features/microblaze-with-stack-protect.c: Regenerate.
	* features/microblaze.c: Regenerate.
	* features/mips-dsp-linux.c: Regenerate.
	* features/mips-linux.c: Regenerate.
	* features/mips64-dsp-linux.c: Regenerate.
	* features/mips64-linux.c: Regenerate.
	* features/nds32.c: Regenerate.
	* features/nios2.c: Regenerate.
	* features/or1k.c: Regenerate.
	* features/rs6000/powerpc-32.c: Regenerate.
	* features/rs6000/powerpc-32l.c: Regenerate.
	* features/rs6000/powerpc-403.c: Regenerate.
	* features/rs6000/powerpc-403gc.c: Regenerate.
	* features/rs6000/powerpc-405.c: Regenerate.
	* features/rs6000/powerpc-505.c: Regenerate.
	* features/rs6000/powerpc-601.c: Regenerate.
	* features/rs6000/powerpc-602.c: Regenerate.
	* features/rs6000/powerpc-603.c: Regenerate.
	* features/rs6000/powerpc-604.c: Regenerate.
	* features/rs6000/powerpc-64.c: Regenerate.
	* features/rs6000/powerpc-64l.c: Regenerate.
	* features/rs6000/powerpc-7400.c: Regenerate.
	* features/rs6000/powerpc-750.c: Regenerate.
	* features/rs6000/powerpc-860.c: Regenerate.
	* features/rs6000/powerpc-altivec32.c: Regenerate.
	* features/rs6000/powerpc-altivec32l.c: Regenerate.
	* features/rs6000/powerpc-altivec64.c: Regenerate.
	* features/rs6000/powerpc-altivec64l.c: Regenerate.
	* features/rs6000/powerpc-e500.c: Regenerate.
	* features/rs6000/powerpc-e500l.c: Regenerate.
	* features/rs6000/powerpc-isa205-32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-64l.c: Regenerate.
	* features/rs6000/powerpc-isa205-altivec32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-altivec64l.c: Regenerate.
	* features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-isa205-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa205-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-isa207-htm-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa207-htm-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-isa207-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-isa207-vsx64l.c: Regenerate.
	* features/rs6000/powerpc-vsx32.c: Regenerate.
	* features/rs6000/powerpc-vsx32l.c: Regenerate.
	* features/rs6000/powerpc-vsx64.c: Regenerate.
	* features/rs6000/powerpc-vsx64l.c: Regenerate.
	* features/rs6000/rs6000.c: Regenerate.
	* features/rx.c: Regenerate.
	* features/s390-gs-linux64.c: Regenerate.
	* features/s390-linux32.c: Regenerate.
	* features/s390-linux32v1.c: Regenerate.
	* features/s390-linux32v2.c: Regenerate.
	* features/s390-linux64.c: Regenerate.
	* features/s390-linux64v1.c: Regenerate.
	* features/s390-linux64v2.c: Regenerate.
	* features/s390-te-linux64.c: Regenerate.
	* features/s390-tevx-linux64.c: Regenerate.
	* features/s390-vx-linux64.c: Regenerate.
	* features/s390x-gs-linux64.c: Regenerate.
	* features/s390x-linux64.c: Regenerate.
	* features/s390x-linux64v1.c: Regenerate.
	* features/s390x-linux64v2.c: Regenerate.
	* features/s390x-te-linux64.c: Regenerate.
	* features/s390x-tevx-linux64.c: Regenerate.
	* features/s390x-vx-linux64.c: Regenerate.
	* mips-tdep.c (_initialize_mips_tdep): Release unique_ptr returned
	from allocate_target_description.
	* target-descriptions.c (allocate_target_description): Update
	return type.
	(print_c_tdesc::visit_pre): Release unique_ptr returned from
	allocate_target_description.

gdbserver/ChangeLog:

	* linux-low.cc (linux_process_target::handle_extended_wait):
	Release the unique_ptr returned from allocate_target_description.
	* linux-riscv-low.cc (riscv_target::low_arch_setup): Likewise.
	* linux-x86-low.cc (tdesc_amd64_linux_no_xml): Change type.
	(tdesc_i386_linux_no_xml): Change type.
	(x86_linux_read_description): Borrow pointer from unique_ptr
	object.
	(x86_target::get_ipa_tdesc_idx): Likewise.
	(initialize_low_arch): Likewise.
	* tdesc.cc (allocate_target_description): Update return type.

gdbsupport/ChangeLog:

	* tdesc.h (allocate_target_description): Update return type.
2020-10-08 10:14:14 +01:00
Tom Tromey
db92ac4568 Use arrays rather than pointers for global string constants
My understanding is that it's mildly better to use a static const
array, as opposed to a "const char *", for a global string constant,
when possible.  This makes sense to me because the pointer requires a
load from an address, whereas the array is just the address.

So, I searched for these in gdb and gdbserver.  This patch fixes the
ones I found.

gdb/ChangeLog
2020-09-15  Tom Tromey  <tromey@adacore.com>

	* unittests/memory-map-selftests.c (valid_mem_map): Now array.
	* ui-style.c (ansi_regex_text): Now array.
	* rust-exp.y (number_regex_text): Now array.
	* linespec.c (linespec_quote_characters): Now array.
	* jit.c (jit_break_name, jit_descriptor_name, reader_init_fn_sym):
	Now arrays.

gdbserver/ChangeLog
2020-09-15  Tom Tromey  <tromey@adacore.com>

	* linux-x86-low.cc (xmltarget_i386_linux_no_xml)
	(xmltarget_amd64_linux_no_xml): Now arrays.
2020-09-15 08:38:22 -06:00
Simon Marchi
b315b67d7a gdbserver: fix memory leak when handling qsupported packet
When building gdbserver with AddressSanitizer, I get this annoying
little leak when gdbserver exits:

==307817==ERROR: LeakSanitizer: detected memory leaks

    Direct leak of 14 byte(s) in 1 object(s) allocated from:
        #0 0x7f7fd4256459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
        #1 0x563bef981b80 in xmalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:60
        #2 0x563befb53301 in xstrdup /home/simark/src/binutils-gdb/libiberty/xstrdup.c:34
        #3 0x563bef9d742b in handle_query /home/simark/src/binutils-gdb/gdbserver/server.cc:2286
        #4 0x563bef9ed0b7 in process_serial_event /home/simark/src/binutils-gdb/gdbserver/server.cc:4061
        #5 0x563bef9f1d9e in handle_serial_event(int, void*) /home/simark/src/binutils-gdb/gdbserver/server.cc:4402
        #6 0x563befb0ec65 in handle_file_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:548
        #7 0x563befb0f49f in gdb_wait_for_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:673
        #8 0x563befb0d4a1 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:215
        #9 0x563bef9e721a in start_event_loop /home/simark/src/binutils-gdb/gdbserver/server.cc:3484
        #10 0x563bef9eb90a in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3875
        #11 0x563bef9ec2c7 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:3961
        #12 0x7f7fd3330001 in __libc_start_main (/usr/lib/libc.so.6+0x27001)

    SUMMARY: AddressSanitizer: 14 byte(s) leaked in 1 allocation(s).

This is due to the handling of unknown qsupported features in
handle_query.  The `qsupported` vector is built, containing all the
feature names received from GDB.  As we iterate on them, when we
encounter unknown ones, we move them at the beginning of the vector, in
preparation of passing this vector of unknown features down to the
target (which may know about them).

When moving these unknown features to other slots in the vector, we
overwrite other pointers without freeing them, which therefore leak.

An easy fix would be to add a `free` when doing the move.  However, I
think this is a good opportunity to sprinkle a bit of automatic memory
management in this code.

So, use a vector of std::string which owns all the entries.  And use a
separate vector (that doesn't own the entries) for the unknown ones,
which is then passed to target_process_qsupported.

Given that the `c_str` method of std::string returns a `const char *`,
it follows that process_stratum_target::process_qsupported must accept a
`const char **` instead of a `char **`.  And while at it, change the
pointer + size paramters to use an array_view instead.

gdbserver/ChangeLog:

	* server.cc (handle_query): Use std::vector of
	std::string for `qsupported` vector.  Use separate
	vector for unknowns.
	* target.h (class process_stratum_target) <process_qsupported>:
	Change parameters to array_view of const char *.
	(target_process_qsupported): Remove `count` parameter.
	* target.cc (process_stratum_target::process_qsupported): Change
	parameters to array_view of const char *.
	* linux-x86-low.cc (class x86_target) <process_qsupported>:
	Likewise.

Change-Id: I97f133825faa6d7abbf83a58504eb0ba77462812
2020-07-13 22:27:01 -04:00
Simon Marchi
1eb3991427 gdb, gdbserver: remove configure check for fs_base/gs_base in user_regs_struct
I recently stumbled on this code mentioning Linux kernel 2.6.25, and
thought it could be time for some spring cleaning (newer GDBs probably
don't need to supports 12-year old kernels).  I then found that the
"legacy" case is probably broken anyway, which gives an even better
motivation for its removal.

In short, this patch removes the configure checks that check if
user_regs_struct contains the fs_base/gs_base fields and adjusts all
uses of the HAVE_STRUCT_USER_REGS_STRUCT_{FS,GS}_BASE macros.  The
longer explanation/rationale follows.

Apparently, Linux kernels since 2.6.25 (that's from 2008) have been
reliably providing fs_base and gs_base as part of user_regs_struct.
Commit df5d438e33d7 in the Linux kernel [1] seems related.  This means
that we can get these values by reading registers with PTRACE_GETREGS.
Previously, these values were obtained using a separate
PTRACE_ARCH_PRCTL ptrace call.

First, I'm not even sure the configure check was really right in the
first place.

The user_regs_struct used by GDB comes from
/usr/include/x86_64-linux-gnu/sys/user.h (or equivalent on other
distros) and is provided by glibc.  glibc has had the fs_base/gs_base
fields in there for a very long time, at least since this commit from
2001 [2].  The Linux kernel also has its version of user_regs_struct,
which I think was exported to user-space at some point.  It included the
fs_base/gs_base fields since at least this 2002 commit [3].  In any
case, my conclusion is that the fields were there long before the
aforementioned Linux kernel commit.  The kernel commit didn't add these
fields, it only made sure that they have reliable values when obtained
with PTRACE_GETREGS.

So, checking for the presence of the fs_base/gs_base fields in struct
user_regs_struct doesn't sound like a good way of knowing if we can
reliably get the fs_base/gs_base values from PTRACE_GETREGS.  My guess
is that if we were using that strategy on a < 2.6.25 kernel, things
would not work correctly:

- configure would find that the user_regs_struct has the fs_base/gs_base
  fields (which are probided by glibc anyway)
- we would be reading the fs_base/gs_base values using PTRACE_GETREGS,
  for which the kernel would provide unreliable values

Second, I have tried to see how things worked by forcing GDB to not use
fs_base/gs_base from PTRACE_GETREGS (forcing it to use the "legacy"
code, by configuring with

  ac_cv_member_struct_user_regs_struct_gs_base=no ac_cv_member_struct_user_regs_struct_fs_base=no

Doing so breaks writing registers back to the inferior.  For example,
calling an inferior functions gives an internal error:

    (gdb) p malloc(10)
    /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408: internal-error: invalid i387 regnum 152

The relevant last frames where this error happens are:

    #8  0x0000563123d262fc in internal_error (file=0x563123e93fd8 "/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c", line=1408, fmt=0x563123e94482 "invalid i387 regnum %d") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
    #9  0x0000563123047d0d in i387_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408
    #10 0x0000563122c69e8a in amd64_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/amd64-tdep.c:3448
    #11 0x0000563122c5e94c in amd64_linux_nat_target::store_registers (this=0x56312515fd10 <the_amd64_linux_nat_target>, regcache=0x5631269453f0, regnum=152) at /home/smarchi/src/binutils-gdb/gdb/amd64-linux-nat.c:335
    #12 0x00005631234c8c80 in target_store_registers (regcache=0x5631269453f0, regno=152) at /home/smarchi/src/binutils-gdb/gdb/target.c:3485
    #13 0x00005631232e8df7 in regcache::raw_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:765
    #14 0x00005631232e8f0c in regcache::cooked_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:778
    #15 0x00005631232e75ec in regcache::restore (this=0x5631269453f0, src=0x5631275eb130) at /home/smarchi/src/binutils-gdb/gdb/regcache.c:283
    #16 0x0000563123083fc4 in infcall_suspend_state::restore (this=0x5631273ed930, gdbarch=0x56312718cf20, tp=0x5631270bca90, regcache=0x5631269453f0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9103
    #17 0x0000563123081eed in restore_infcall_suspend_state (inf_state=0x5631273ed930) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9151

The problem seems to be that amd64_linux_nat_target::store_registers
calls amd64_native_gregset_supplies_p to know whether gregset provides
fs_base.  When !HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE,
amd64_native_gregset_supplies_p returns false.  store_registers
therefore assumes that it must be an "xstate" register.  This is of
course wrong, and that leads to the failed assertion when
i387_collect_xsave doesn't recognize the register.

amd64_linux_nat_target::store_registers could probably be fixed to
handle this case, but I don't think it's worth it, given that it would
only be to support very old kernels.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5d438e33d7fc914ba9b6e0d6b019a8966c5fcc
[2] https://sourceware.org/git/?p=glibc.git;a=commit;h=c9cf6ddeebb7bb
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=88e4bc32686ebd0b1111a94f93eba2d334241f68

gdb/ChangeLog:

	* configure.ac: Remove check for fs_base/gs_base in
	user_regs_struct.
	* configure: Re-generate.
	* config.in: Re-generate.
	* amd64-nat.c (amd64_native_gregset_reg_offset): Adjust.
	* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers,
	amd64_linux_nat_target::store_registers, ps_get_thread_area, ): Adjust.

gdbserver/ChangeLog:

	* configure.ac: Remove check for fs_base/gs_base in
	user_regs_struct.
	* configure: Re-generate.
	* config.in: Re-generate.
	* linux-x86-low.cc (x86_64_regmap, x86_fill_gregset,
	x86_store_gregset): Adjust.
2020-04-27 10:47:50 -04:00
Tankut Baris Aktemur
0dd7b52ede gdbserver/linux-low: delete 'linux_target_ops' and 'the_low_target'
All the linux target ops have been moved into linux_process_target
as methods.  The 'linux_target_ops' struct and its instantiations
are now obsolete.  Delete them.

gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* linux-low.h (struct linux_target_ops): Remove.
	(the_low_target): Remove.
	* linux-x86-low.cc (the_low_target): Remove.
	* linux-aarch64-low.cc (the_low_target): Ditto.
	* linux-arm-low.cc (the_low_target): Ditto.
	* linux-bfin-low.cc (the_low_target): Ditto.
	* linux-cris-low.cc (the_low_target): Ditto.
	* linux-crisv32-low.cc (the_low_target): Ditto.
	* linux-ia64-low.cc (the_low_target): Ditto.
	* linux-m32r-low.cc (the_low_target): Ditto.
	* linux-m68k-low.cc (the_low_target): Ditto.
	* linux-mips-low.cc (the_low_target): Ditto.
	* linux-nios2-low.cc (the_low_target): Ditto.
	* linux-ppc-low.cc (the_low_target): Ditto.
	* linux-riscv-low.cc (the_low_target): Ditto.
	* linux-s390-low.cc (the_low_target): Ditto.
	* linux-sh-low.cc (the_low_target): Ditto.
	* linux-sparc-low.cc (the_low_target): Ditto.
	* linux-tic6x-low.cc (the_low_target): Ditto.
	* linux-tile-low.cc (the_low_target): Ditto.
	* linux-xtensa-low.cc (the_low_target): Ditto.
2020-04-02 15:11:32 +02:00
Tankut Baris Aktemur
fc5ecdb630 gdbserver/linux-low: turn 'get_ipa_tdesc_idx' into a method
gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	Remove the 'get_ipa_tdesc_idx' linux target op and let a concrete
	linux target define the op by overriding the declaration in
	process_stratum_target.

	* linux-low.h (struct linux_target_ops): Remove the op.
	(class linux_process_target) <get_ipa_tdesc_idx>: Remove.
	* linux-low.cc (linux_process_target::get_ipa_tdesc_idx): Remove.
	* linux-x86-low.cc (class x86_target) <get_ipa_tdesc_idx>: Declare.
	(x86_get_ipa_tdesc_idx): Turn into...
	(x86_target::get_ipa_tdesc_idx): ...this.
	(the_low_target): Remove the op field.
	* linux-ppc-low.cc (class ppc_target) <get_ipa_tdesc_idx>: Declare.
	(ppc_get_ipa_tdesc_idx): Turn into...
	(ppc_target::get_ipa_tdesc_idx): ...this.
	(the_low_target): Remove the op field.
	* linux-s390-low.cc (class s390_target) <get_ipa_tdesc_idx>: Declare.
	(s390_get_ipa_tdesc_idx): Turn into...
	(s390_target::get_ipa_tdesc_idx): ...this.
	(the_low_target): Remove the op field.
2020-04-02 15:11:32 +02:00
Tankut Baris Aktemur
9eedd27d42 gdbserver/linux-low: turn 'get_syscall_trapinfo' into a method
gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	Turn the 'get_syscall_trapinfo' linux target op into a method
	of process_stratum_target.

	* linux-low.h (struct linux_target_ops): Remove the op.
	(class linux_process_target) <get_syscall_trapinfo>
	<gdb_catch_this_syscall>
	<low_supports_catch_syscall>
	<low_get_syscall_trapinfo>: Declare.
	* linux-low.cc (get_syscall_trapinfo): Turn into...
	(linux_process_target::get_syscall_trapinfo): ...this.
	(linux_process_target::low_get_syscall_trapinfo): Define.
	(gdb_catch_this_syscall_p): Turn into...
	(linux_process_target::gdb_catch_this_syscall): ...this.
	(linux_process_target::low_supports_catch_syscall): Define.

	Update the callers below.

	(linux_process_target::wait_1)
	(linux_process_target::supports_catch_syscall)

	* linux-x86-low.cc (class x86_target) <low_supports_catch_syscall>
	<low_get_syscall_trapinfo>: Declare.
	(x86_target::low_supports_catch_syscall): Define.
	(x86_get_syscall_trapinfo): Turn into...
	(x86_target::low_get_syscall_trapinfo): ...this.
	(the_low_target): Remove the op field.
	* linux-aarch64-low.cc (class aarch64_target)
	<low_supports_catch_syscall>
	<low_get_syscall_trapinfo>: Declare.
	(aarch64_target::low_supports_catch_syscall): Define.
	(aarch64_get_syscall_trapinfo): Turn into...
	(aarch64_target::low_get_syscall_trapinfo): ...this.
	(the_low_target): Remove the op field.
	* linux-arm-low.cc (class arm_target) <low_supports_catch_syscall>
	<low_get_syscall_trapinfo>: Declare.
	(arm_target::low_supports_catch_syscall): Define.
	(arm_get_syscall_trapinfo): Turn into...
	(arm_target::low_get_syscall_trapinfo): ...this.
	(the_low_target): Remove the op field.
	* linux-ppc-low.cc (the_low_target): Remove the op field.
	* linux-s390-low.cc (the_low_target): Remove the op field.
2020-04-02 15:11:31 +02:00
Tankut Baris Aktemur
b31cdfa69f gdbserver/linux-low: turn 'supports_hardware_single_step' into a method
All the linux low targets except arm define the
'supports_hardware_single_step' op to return true.  Hence, we override
the method to return true in linux_process_target, and remove the
definitions in all the linux low targets but arm.

gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	Remove the 'supports_hardware_single_step' linux target op and
	override the process_stratum_target's op definition in
	linux_process_target to return true.

	* linux-low.h (struct linux_target_ops): Remove the op.
	(class linux_process_target) <finish_step_over>
	<maybe_hw_step>: Declare.
	* linux-low.cc (can_hardware_single_step): Remove.
	(maybe_hw_step): Turn into...
	(linux_process_target::maybe_hw_step): ...this.
	(finish_step_over): Turn into...
	(linux_process_target::finish_step_over): ...this.
	(linux_process_target::supports_hardware_single_step): Update
	to return true.

	Update the callers below.

	(linux_process_target::single_step)
	(linux_process_target::resume_one_lwp_throw)

	* linux-arm-low.cc (class arm_target)
	<supports_hardware_single_step>: Declare.
	(arm_supports_hardware_single_step): Turn into...
	(arm_target::supports_hardware_single_step): ...this.
	(the_low_target): Remove the op field.
	* linux-x86-low.cc (x86_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-aarch64-low.cc (aarch64_supports_hardware_single_step):
	Remove.
	(the_low_target): Remove the op field.
	* linux-bfin-low.cc (bfin_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-crisv32-low.cc (cris_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-m32r-low.cc (m32r_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-m68k-low.cc (m68k_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-ppc-low.cc (ppc_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-s390-low.cc (s390_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-sh-low.cc (sh_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-tic6x-low.cc (tic6x_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-tile-low.cc (tile_supports_hardware_single_step): Remove.
	(the_low_target): Remove the op field.
	* linux-xtensa-low.cc (xtensa_supports_hardware_single_step):
	Remove.
	(the_low_target): Remove the op field.
2020-04-02 15:11:31 +02:00
Tankut Baris Aktemur
9cfd871551 gdbserver/linux-low: turn 'supports_range_stepping' into a method
gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	Turn the 'supports_range_stepping' linux target op into a method
	of linux_process_target.

	* linux-low.h (struct linux_target_ops): Remove the op.
	(class linux_process_target) <low_supports_range_stepping>: Declare.
	* linux-low.cc (linux_process_target::low_supports_range_stepping):
	Define.
	(linux_process_target::supports_range_stepping): Update the call
	site.
	* linux-x86-low.cc (class x86_target)
	<low_supports_range_stepping>: Declare.
	(x86_supports_range_stepping): Turn into...
	(x86_target::low_supports_range_stepping): ...this.
	(the_low_target): Remove the op field.
	* linux-aarch64-low.cc (class aarch64_target)
	<low_supports_range_stepping>: Declare.
	(aarch64_supports_range_stepping): Turn into...
	(aarch64_target::low_supports_range_stepping): ...this.
	(the_low_target): Remove the op field.
	* linux-arm-low.cc (the_low_target): Remove the op field.
	* linux-bfin-low.cc (the_low_target): Ditto.
	* linux-crisv32-low.cc (the_low_target): Ditto.
	* linux-m32r-low.cc (the_low_target): Ditto.
	* linux-m68k-low.cc (the_low_target): Ditto.
	* linux-ppc-low.cc (the_low_target): Ditto.
	* linux-s390-low.cc (the_low_target): Ditto.
	* linux-sh-low.cc (the_low_target): Ditto.
	* linux-tic6x-low.cc (the_low_target): Ditto.
	* linux-tile-low.cc (the_low_target): Ditto.
	* linux-xtensa-low.cc (the_low_target): Ditto.
2020-04-02 15:11:31 +02:00
Tankut Baris Aktemur
ab64c99982 gdbserver/linux-low: turn 'emit_ops' into a method
gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	Remove the 'emit_ops' linux target ops and let the concrete
	linux target define the op by overriding the declaration of
	process_stratum_target.

	* linux-low.h (struct linux_target_ops): Remove the op.
	(class linux_process_target) <emit_ops>: Remove.
	* linux-low.cc (linux_process_target::emit_ops): Remove.
	* linux-x86-low.cc (class x86_target) <emit_ops>: Declare.
	(x86_emit_ops): Turn into...
	(x86_target::emit_ops): ...this.
	(the_low_target): Remove the op field.
	* linux-aarch64-low.cc (class aarch64_target) <emit_ops>: Declare.
	(aarch64_emit_ops): Turn into...
	(aarch64_target::emit_ops): ...this.
	(the_low_target): Remove the op field.
	* linux-ppc-low.cc (class ppc_target) <emit_ops>: Declare.
	(ppc_emit_ops): Turn into...
	(ppc_target::emit_ops): ...this.
	(the_low_target): Remove the op field.
	* linux-s390-low.cc (class s390_target) <emit_ops>: Declare.
	(s390_emit_ops): Turn into...
	(s390_target::emit_ops): ...this.
	(the_low_target): Remove the op field.
	* linux-arm-low.cc (the_low_target): Remove the op field.
	* linux-bfin-low.cc (the_low_target): Ditto.
	* linux-crisv32-low.cc (the_low_target): Ditto.
	* linux-m32r-low.cc (the_low_target): Ditto.
	* linux-m68k-low.cc (the_low_target): Ditto.
	* linux-sh-low.cc (the_low_target): Ditto.
	* linux-tic6x-low.cc (the_low_target): Ditto.
	* linux-tile-low.cc (the_low_target): Ditto.
	* linux-xtensa-low.cc (the_low_target): Ditto.
2020-04-02 15:11:30 +02:00
Tankut Baris Aktemur
809a0c354b gdbserver/linux-low: turn fast tracepoint ops into methods
gdbserver/ChangeLog:
2020-04-02  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	Remove the 'install_fast_tracepoint_jump_pad' and
	'get_min_fast_tracepoint_insn_len' linux target ops to let the
	concrete linux target define the ops by overriding the declarations
	of process_stratum_target.

	* linux-low.h (struct linux_target_ops): Remove the ops.
	(class linux_process_target) <supports_fast_tracepoints>
	<install_fast_tracepoint_jump_pad>
	<get_min_fast_tracepoint_insn_len>: Remove.
	* linux-low.cc (linux_process_target::supports_fast_tracepoints)
	(linux_process_target::install_fast_tracepoint_jump_pad)
	(linux_process_target::get_min_fast_tracepoint_insn_len): Remove.
	* linux-x86-low.cc (class x86_target) <supports_fast_tracepoints>
	<install_fast_tracepoint_jump_pad>
	<get_min_fast_tracepoint_insn_len>: Declare.
	(x86_target::supports_fast_tracepoints): Define.
	(x86_install_fast_tracepoint_jump_pad): Turn into...
	(x86_target::install_fast_tracepoint_jump_pad): ...this.
	(x86_get_min_fast_tracepoint_insn_len): Turn into...
	(x86_target::get_min_fast_tracepoint_insn_len): ...this.
	(the_low_target): Remove the op fields.
	* linux-aarch64-low.cc (class aarch64_target)
	<supports_fast_tracepoints>
	<install_fast_tracepoint_jump_pad>
	<get_min_fast_tracepoint_insn_len>: Declare.
	(aarch64_target::supports_fast_tracepoints): Define.
	(aarch64_install_fast_tracepoint_jump_pad): Turn into...
	(aarch64_target::install_fast_tracepoint_jump_pad): ...this.
	(aarch64_get_min_fast_tracepoint_insn_len): Turn into...
	(aarch64_target::get_min_fast_tracepoint_insn_len): ...this.
	(the_low_target): Remove the op fields.
	* linux-ppc-low.cc (class ppc_target) <supports_fast_tracepoints>
	<install_fast_tracepoint_jump_pad>
	<get_min_fast_tracepoint_insn_len>: Declare.
	(ppc_target::supports_fast_tracepoints): Define.
	(ppc_install_fast_tracepoint_jump_pad): Turn into...
	(ppc_target::install_fast_tracepoint_jump_pad): ...this.
	(ppc_get_min_fast_tracepoint_insn_len): Turn into...
	(ppc_target::get_min_fast_tracepoint_insn_len): ...this.
	(the_low_target): Remove the op fields.
	* linux-s390-low.cc (class s390_target) <supports_fast_tracepoints>
	<install_fast_tracepoint_jump_pad>
	<get_min_fast_tracepoint_insn_len>: Declare.
	(s390_target::supports_fast_tracepoints): Define.
	(s390_install_fast_tracepoint_jump_pad): Turn into...
	(s390_target::install_fast_tracepoint_jump_pad): ...this.
	(s390_get_min_fast_tracepoint_insn_len): Turn into...
	(s390_target::get_min_fast_tracepoint_insn_len): ...this.
	(the_low_target): Remove the op fields.
	* linux-arm-low.cc (the_low_target): Remove the op fields.
	* linux-bfin-low.cc (the_low_target): Ditto.
	* linux-crisv32-low.cc (the_low_target): Ditto.
	* linux-m32r-low.cc (the_low_target): Ditto.
	* linux-m68k-low.cc (the_low_target): Ditto.
	* linux-sh-low.cc (the_low_target): Ditto.
	* linux-tic6x-low.cc (the_low_target): Ditto.
	* linux-tile-low.cc (the_low_target): Ditto.
	* linux-xtensa-low.cc (the_low_target): Ditto.
2020-04-02 15:11:30 +02:00