This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH 1/1] Fix broken GDB build after adding Bound table support for i386.


Joel,

The message is this one:
----
/users/wtedesch/external/binutils-gdb/gdb/i386-tdep.c: In function 'i386_mpx_get_bt_entry':
/users/wtedesch/external/binutils-gdb/gdb/i386-tdep.c:8681:7: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
----


Here is the reason:

-----
  if (gdbarch_ptr_bit (gdbarch) == 64)
    {
      mpx_bd_mask = MPX_BD_MASK;    <- Here. MPX_BD_MASK is #define MPX_BD_MASK     0xfffffff00000ULL	/* select bits [47:20]  */
      bd_ptr_r_shift = 20;
      bd_ptr_l_shift = 3;
      bt_select_r_shift = 3;
      bt_select_l_shift = 5;
      bt_mask = MPX_BT_MASK;
    }
  else
    {
      mpx_bd_mask = MPX_BD_MASK_32;
      bd_ptr_r_shift = 12;
      bd_ptr_l_shift = 2;
      bt_select_r_shift = 2;
      bt_select_l_shift = 4;
      bt_mask = MPX_BT_MASK_32;
    }
----


Thanks and regards,
-Fred
-----Original Message-----
From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
Sent: Wednesday, June 10, 2015 4:13 PM
To: Tedeschi, Walfred
Cc: eliz@gnu.org; gdb-patches@sourceware.org
Subject: Re: [PATCH 1/1] Fix broken GDB build after adding Bound table support for i386.

> Types used for some variables could not be used for 32 bits.
> This patch changes uses larger types to accommodate the biggest 
> integer possible.
> Documentation was also affected, once a different version of texinfo 
> the docs could not be build.
> 
> 2015-06-10  Walfred Tedeschi  <walfred.tedeschi@intel.com>
> 
> 	* i386-tdep.c (i386_mpx_get_bt_entry): Exchange CORE_ADDR by
> 	ULONGEST.
> 
> doc:
> 	gdb.textinfo (i386): Fix "@end table" end and "@table" placement.

Can you post the error messages, so we can understand why this is necessary? I'm also wondering whether you really want to return a CORE_ADDR which is the sum of 2 ULONGEST now...

--
Joel
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]