public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Luis Machado <luis.machado@arm.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [gdb/tdep] Fix ARM_LINUX_JB_PC_EABI
Date: Fri, 7 Jun 2024 11:01:30 +0200	[thread overview]
Message-ID: <4f651fb5-ef55-4c9e-b1d0-62d438ec2529@suse.de> (raw)
In-Reply-To: <93a5db05-8697-42f0-a419-2d5f56569006@arm.com>

On 6/7/24 10:40, Luis Machado wrote:
> On 6/7/24 09:14, Tom de Vries wrote:
>> In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1
>> since glibc 2.20.
>>
>> See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and
>> setjmp.").
>>
>> Update it, allowing us to run into the gdb/26967 kfail.
>>
>> Tested on arm-linux.
>>
>> PR arm/tdep
>> Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089
>> ---
>>   gdb/arm-linux-tdep.c | 18 ++++++++++++++++--
>>   1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c
>> index 43869e4fcfe..b0b6f3646f1 100644
>> --- a/gdb/arm-linux-tdep.c
>> +++ b/gdb/arm-linux-tdep.c
>> @@ -101,12 +101,26 @@ static const gdb_byte arm_linux_thumb2_le_breakpoint[] = { 0xf0, 0xf7, 0x00, 0xa
>>      particular the FP model) and also (possibly) the C Library.
>>   
>>      For glibc, eglibc, and uclibc the following holds:  If the FP model is
>> -   SoftVFP or VFP (which implies EABI) then the PC is at offset 9 in the
>> +   SoftVFP or VFP (which implies EABI) then the PC is at offset 1 or 9 in the
>>      buffer.  This is also true for the SoftFPA model.  However, for the FPA
>>      model the PC is at offset 21 in the buffer.  */
>>   #define ARM_LINUX_JB_ELEMENT_SIZE	ARM_INT_REGISTER_SIZE
>>   #define ARM_LINUX_JB_PC_FPA		21
>> -#define ARM_LINUX_JB_PC_EABI		9
>> +#ifdef __UCLIBC__
>> +# define ARM_LINUX_JB_PC_EABI		9
>> +#else
>> +# ifdef __GLIBC__
>> +#  if __GLIBC_PREREQ(2, 20)
>> +/* This has been 1 since glibc 2.20, see glibc commit 80a56cc3ee ("ARM: Add
>> +   SystemTap probes to longjmp and setjmp.").  */
>> +#   define ARM_LINUX_JB_PC_EABI		1
>> +#  else
>> +#   define ARM_LINUX_JB_PC_EABI		9
>> +#  endif
>> +# else
>> +#  define ARM_LINUX_JB_PC_EABI		9
>> +# endif
>> +#endif
>>   
>>   /*
>>      Dynamic Linking on ARM GNU/Linux
>>
>> base-commit: f9478936896ada7786e8d68622f6e6ff78b97b0d
> 
> Aren't those offsets supposed to be discovered at runtime, as opposed
> to compile-time? We're looking at whether the inferior is built with
> uclibc/glibc, and not gdb's own library versions, right?

This is a best effort, in absence of implementation of these enhancement 
PRs:
- add uclibc osabi (PR31854), and
- newlibc osabi enablement on arm (PR31856).

Using the compile time discovery ensures that at least a gdb build 
against a system uclibc or newlib will get the correct values to use on 
that system.

Likewise, there's no versioning in the osabi, so we use compile time 
discovery for the glibc version.  This is not correct, but it's the best 
we can do in absence of such versioning.

Thanks,
- Tom

  reply	other threads:[~2024-06-07  9:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  8:14 Tom de Vries
2024-06-07  8:40 ` Luis Machado
2024-06-07  9:01   ` Tom de Vries [this message]
2024-06-07  9:52     ` Luis Machado
     [not found]     ` <87zfrwk9tu.fsf@tromey.com>
2024-06-08  8:31       ` Tom de Vries
2024-06-11  9:59         ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f651fb5-ef55-4c9e-b1d0-62d438ec2529@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).