Re: [PATCH 02/12] fbsd-nat: Add helper routines for register sets using PT_[G]SETREGSET.

[John Baldwin <jhb@FreeBSD.org>]

On 3/24/22 1:51 AM, Luis Machado wrote:
> On 3/23/22 21:00, John Baldwin wrote:
>> FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET
>> operations to fetch a register set named by an ELF note type.  These
>> helper routines provide helpers to check for a register set's
>> existence, fetch registers for a register set, and store registers to
>> a register set.
>> ---
>>    gdb/fbsd-nat.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>    gdb/fbsd-nat.h | 42 +++++++++++++++++++++++++++++
>>    2 files changed, 114 insertions(+)
>>
>> diff --git a/gdb/fbsd-nat.c b/gdb/fbsd-nat.c
>> index 934fdbad6ef..84abdd9a322 100644
>> --- a/gdb/fbsd-nat.c
>> +++ b/gdb/fbsd-nat.c
>> @@ -1772,6 +1772,78 @@ fbsd_nat_target::store_register_set (struct regcache *regcache, int regnum,
>>      return false;
>>    }
>>    
>> +#ifdef PT_GETREGSET
> 
> Instead of ifdef-ing the entire block of code, wouldn't it be better to
> conditionally define the constant and have the code do checks at runtime?
> 
> If GDB is built on a machine without the proper headers and copied onto
> a machine with support for PT_GETREGSET, it won't be able to use this
> improvement. On the other hand, if we build GDB on a machine with the
> headers, but copy it into a machine without support for PT_GETREGSET,
> things will break, no?

FreeBSD does not generally support forwards compatibility (the second case
of a newer binary on an older kernel), only backwards compatibility.
However, it is true that in the use cases for PT_GETREGSET for the
foreseeable future, they will all be conditioned on a runtime check
via the 'have_regset' function enabling an architecture feature, so I
could add a fallback for the macro and always enable these functions.  I
will go ahead and make that change.

-- 
John Baldwin