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

[Joel Brobecker <brobecker@adacore.com>]

> I am considering using a guard on the code like bellow:
>   if (gdbarch_ptr_bit (gdbarch) == 64)
>     {
> #ifdef __x86_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
>  error(_("operation not supported yet")
> #endif
>     }
>   else
>     {
> 
> I consider that debugging a 64 bit application with a 32 bit debugger
> is not supported fully, but I might be wrong.
> In any case would this be an acceptable solution? 

First, my understanding of the the general principles used in
the GDB project:

For native compilers, we would indeed generally say 32bit GDB can only
debug 32bit applications, but not as an absolute rule. That limitation
is usually not because of GDB but rather because of a limitation in
the underlying systems which don't support 64bit debugging from 32bit
programs.

In your case, we are in a slightly different situation, however, as
we are in what we call "target" (-tdep) code, rather than "native"
(-nat). In that case, if it is difficult to support 32bit debugging
64bit app + something of little interest, then we can indeed consider
keeping that scenario unsupported. But we should otherwise try looking
at whether we can support it.

Now, looking more specifically at your situation, it seems to me
that supporting 64bit target if CORE_ADDR is 32bit is going to be,
erm, hard. So, something along the lines above would indeed be
the best we can do. You have to be careful to conditionalize on
something else that __x86_64__, though, as the host's CPU might
not be an x86/x86_64...

-- 
Joel