This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Fix gdbserver build with x86_64-w64-mingw32 -m32
- From: Zach Welch <zwelch at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Mon, 12 Jan 2015 09:54:01 -0800
- Subject: Re: [PATCH] Fix gdbserver build with x86_64-w64-mingw32 -m32
- Authentication-results: sourceware.org; auth=none
- References: <1420825778-8946-1-git-send-email-zwelch at codesourcery dot com> <20150110041728 dot GQ5445 at adacore dot com>
On 01/09/2015 08:17 PM, Joel Brobecker wrote:
>> This patch allows a x86_64-w64-mingw32 toolchain to build a 32-bit
>> gdbserver. Without it, gdbserver attempts to link to the 64-bit
>> register files, resulting in undefined references.
>> * configure.ac: Add check for -m32 on x86_64-*-mingw*.
>> * configure.srv: If using -m32 on x86_64-*-mingw*, use i386
>> instead of amd64 registers.
>> * configure: Regenerated.
>> * aclocal.m4: Regenerated.
> Intuitively, I would say that the proper way to achive a 32bit
> gdbserver is by configuring it using a 32bit triplet, no?
> What happens if you do:
> ./configure --build=i686-pc-mingw32 CFLAGS='-m32'
Actually, I am using i686-pc-linux-gnu as $build. I think you meant to
ask for --host. I am using --host=x86_64-w64-mingw32 CFLAGS=-m32, which
is distinctly different than i686-pc-mingw32. For example, they use
completely different runtime libraries. I think it would be an error to
conflate the two toolchains. Thus, I stand by my patch as the correct
solution for this issue.
Mentor Graphics Corporation