Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jon Turney <jon.turney@dronecode.org.uk>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: recognize 64 bits Windows executables as Cygwin osabi
Date: Mon, 9 Mar 2020 15:39:53 +0000	[thread overview]
Message-ID: <fe42cddd-f49a-ada7-cd78-63e51ede7485@dronecode.org.uk> (raw)
In-Reply-To: <835zfg9hz5.fsf@gnu.org>

On 07/03/2020 17:45, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Simon Marchi <simon.marchi@efficios.com>
>> Date: Sat, 7 Mar 2020 11:51:08 -0500
>>
>>    https://sourceware.org/ml/gdb-patches/2020-03/msg00151.html
>>
>> Currently, loading the 64-bits .exe in a GNU/Linux-hosted GDB ends up calling
>> the svr4 libraries code, which is plain wrong.  By using the Cygwin osabi,
>> at least the right shared libraries functions are used.
>>
>> I agree with what you suggest below, but I think that the current patch is
>> still a step forward and improves things.
> 
> I agree.  I just think we can do better.
> 
>> So what we can do is add an "MS-Windows" osabi and make "Cygwin" and
>> "MS-Windows" functionally equivalent.  Any "pei-i386" or "pei-x86-64"
>> executable would be detected as "MS-Windows".

I believe this suggestion for x86_64 is wrong, in the other direction:
x86_64 Cygwin is LP64, but Windows is LLP64 (See also table in [1])

(This is handled incorrectly in Cygwin at the moment, e.g. in our build 
of gdb 'print sizeof(long)' returns 4)

There was some discussion that these need to be separate osabis 
previously, I think.

[1] https://cygwin.com/faq.html#faq.programming.64bitporting


> That's fine with me, and IMO will be more accurate than calling them
> all "Cygwin", since Cygwin programs are just a peculiar kind of
> Windows executables.
> 
>> If we do such a change, I would like it to be done on top of the current
>> patch, as to not mix concerns.
> 
> I'm okay with that, thanks.


      parent reply	other threads:[~2020-03-10 15:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200307041742.31158-1-simon.marchi@efficios.com>
     [not found] ` <83zhcsa8my.fsf@gnu.org>
2020-03-07 16:51   ` Simon Marchi
2020-03-07 17:45     ` Eli Zaretskii
2020-03-07 18:16       ` Simon Marchi
2020-03-08 14:05       ` Jon Turney
2020-03-10 15:16         ` Eli Zaretskii
2020-03-10 15:45           ` Simon Marchi
2020-03-14 15:35             ` Jon Turney
2020-03-09 15:39       ` Jon Turney [this message]

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=fe42cddd-f49a-ada7-cd78-63e51ede7485@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --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