From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Ulrich Weigand'" <uweigand@de.ibm.com>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [rfc] [0/9] Multi-target support
Date: Mon, 19 Nov 2007 16:35:00 -0000 [thread overview]
Message-ID: <001101c82ac9$c9ca71a0$5d5f54e0$@u-strasbg.fr> (raw)
In-Reply-To: <200711191138.lAJBc20Z024695@d12av02.megacenter.de.ibm.com>
Yes, I started in a new directory.
mkdir build-all
cd build-all
../src/configure --enable-targets=all
make all-gdb
I checked in bfd/bfd.h and BFD_ARCH_SIZE was set to 32
there.
Adding --enable-64-bit-bfd I still
needed to add WERROR_CFLAGS=""
because I got warnings in win32-nat.c,
which implicitly assumes that CORE_ADDR
is 32 bit long.
../../src/gdb/win32-nat.c: In function `handle_output_debug_string':
../../src/gdb/win32-nat.c:884: warning: cast from pointer to integer of
different size
../../src/gdb/win32-nat.c: In function `handle_exception':
../../src/gdb/win32-nat.c:1091: warning: cast from pointer to integer of
different size
../../src/gdb/win32-nat.c: In function `win32_xfer_memory':
../../src/gdb/win32-nat.c:2068: warning: cast to pointer from integer of
different size
../../src/gdb/win32-nat.c:2071: warning: cast to pointer from integer of
different size
../../src/gdb/win32-nat.c:2077: warning: cast to pointer from integer of
different size
In win32_xfer_memory, the parameter memaddr of type CORE_ADDR
is typecasted to LPVOID as parameter of the windows API function
WriteProcessMemory, the fact that this only emits a warning probably means
that
it does the right thing, (that is, to truncate CORE_ADDR to a 32 bit value,
which is it anyhow).
Nevertheless, without the WERROR_CFLAGS="", the build fails.
Should all nat files be able to handle the case where
sizeof(CORE_ADDR) is strictly greater then sizeof( void *)
and do explicit conversion for that?
I also got a problem with the m2-exp.y yacc file
conflicts: 15 shift/reduce, 15 reduce/reduce
conflicts: 5 shift/reduce
conflicts: 34 shift/reduce
/home/Pierre/gdbcvs/build-all/gdb/../../src/gdb/m2-exp.y:354.25-44: warning:
rule never reduced because of conflicts: @2: /* empty */
But after checking, this warning is also present for a simple build without
option.
Pierre
> -----Original Message-----
> From: Ulrich Weigand [mailto:uweigand@de.ibm.com]
> Sent: Monday, November 19, 2007 12:38 PM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org
> Subject: Re: [rfc] [0/9] Multi-target support
>
> Pierre Muller wrote:
>
> > Is the CORE_ADDR size changed according to the target of the
> current tdep
> > file?
>
> CORE_ADDR is defined as bfd_vma, and the latter is supposed to be
> chosen
> according to the selected targets (see the generated bfd/bfd.h file):
>
> /* The word size used by BFD on the host. This may be 64 with a 32
> bit target if the host is 64 bit, or if other 64 bit targets have
> been selected with --enable-targets, or if --enable-64-bit-bfd. */
> #define BFD_ARCH_SIZE 64
>
> Not sure why this didn't work for you ... Did you start from a clean
> build directory? Could you try whether at least explicitly specifying
> --enable-64-bit-bfd works?
>
> Bye,
> Ulrich
>
> --
> Dr. Ulrich Weigand
> GNU Toolchain for Linux on System z and Cell BE
> Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2007-11-19 16:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 1:15 Ulrich Weigand
2007-10-26 7:19 ` Daniel Jacobowitz
2007-10-30 21:54 ` [rfc] [0/9] Multi-target support: Fix show_mipsfpu_command crash Ulrich Weigand
2007-11-17 1:08 ` [rfc] [0/9] Multi-target support Ulrich Weigand
2007-11-19 10:14 ` Pierre Muller
2007-11-19 11:38 ` Ulrich Weigand
2007-11-19 16:35 ` Pierre Muller [this message]
2007-11-19 17:24 ` Ulrich Weigand
2007-11-19 17:28 ` Daniel Jacobowitz
2007-11-20 22:17 ` Ulrich Weigand
2007-11-20 22:23 ` [rfc/rft] --enable-targets=all with 32-bit BFD Ulrich Weigand
2007-11-21 1:01 ` Pedro Alves
2007-11-26 15:30 ` Ulrich Weigand
2007-11-27 3:00 ` Pedro Alves
2007-11-27 17:08 ` Ulrich Weigand
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='001101c82ac9$c9ca71a0$5d5f54e0$@u-strasbg.fr' \
--to=muller@ics.u-strasbg.fr \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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