Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] gdbserver/Windows: crash during connection establishment phase
Date: Fri, 04 May 2018 19:12:00 -0000	[thread overview]
Message-ID: <03cdded5-9f4e-fc1a-366a-1be7cd8b1837@redhat.com> (raw)
In-Reply-To: <20180504185818.htyn2gj2xx5i5s7f@adacore.com>

On 05/04/2018 07:58 PM, Joel Brobecker wrote:
>>> +#ifndef IN_PROCESS_AGENT
>>> +#ifdef __x86_64__
>>> +  static const char *expedite_regs_amd64[] = { "rbp", "rsp", "rip", NULL };
>>> +  tdesc->expedite_regs = expedite_regs_amd64;
>>> +#else /* __x86_64__ */
>>> +  static const char *expedite_regs_i386[] = { "ebp", "esp", "eip", NULL };
>>> +  tdesc->expedite_regs = expedite_regs_i386;
>>> +#endif /* __x86_64__ */
>>> +#endif
>>
>> Won't all x86 ports have the same problem?  I.e., don't
>> nto-x86-low.c:nto_x86_arch_setup and
>> lynx-i386-low.c:lynx_i386_arch_setup need the same treatment?
>> Should we put those arrays in some shared i386 file?
> 
> They probably would, but these are platforms I cannot test at
> the moment, so I didn't want to take a risk and create a situation
> for them. I'm quite happy to adjust the way you suggest.

I think I'd take the risk anyway, even without testing.  (Just like
the original patch that broke them didn't get testing on !Linux
ports.)  They're already most probably broken, so we can't be
making it worse, IMO.

Thanks,
Pedro Alves


  reply	other threads:[~2018-05-04 19:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04 18:30 [Windows GDBserver] Make GDBserver functional again on Windows Joel Brobecker
2018-05-04 18:30 ` [PATCH 2/3] gdbserver/Windows: Fix "no program to debug" error Joel Brobecker
2018-05-10  0:09   ` Pedro Alves
2018-05-10 16:50     ` Joel Brobecker
2018-05-04 18:30 ` [PATCH 3/3] gdbserver/Windows: crash during connection establishment phase Joel Brobecker
2018-05-04 18:46   ` Pedro Alves
2018-05-04 18:58     ` Joel Brobecker
2018-05-04 19:12       ` Pedro Alves [this message]
2018-05-07 21:47         ` Joel Brobecker
2018-05-09 15:54           ` Pedro Alves
2018-05-09 23:09             ` Joel Brobecker
2018-05-09 23:17               ` Pedro Alves
2018-05-10 17:04             ` Joel Brobecker
2018-05-04 20:20   ` Eli Zaretskii
2018-05-04 18:30 ` [PATCH 1/3] [gdbserver/win32] fatal "glob could not process pattern '(null)'" error Joel Brobecker
2018-05-09 23:50   ` Pedro Alves
2018-05-10 16:48     ` Joel Brobecker
2018-05-04 18:41 ` [Windows GDBserver] Make GDBserver functional again on Windows Sergio Durigan Junior
2018-05-04 18:54   ` Joel Brobecker
2018-05-10 18:19 ` Joel Brobecker

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=03cdded5-9f4e-fc1a-366a-1be7cd8b1837@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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