gdb 6.8 selected_byte_order function

gdb 6.8 selected_byte_order function

[Richard Stuckey]

Hello,

I am currently moving the ARC port of gdb from 6.6 on to 6.8, and I am a
little puzzled by the selected_byte_order function in file arch-utils.c;
I wonder if anyone could perhaps enlighten me about it.

The 6.8 code (this function did not exist in 6.6) is

enum bfd_endian
selected_byte_order (void)
{
  if (target_byte_order_user != BFD_ENDIAN_UNKNOWN)
    return gdbarch_byte_order (current_gdbarch);
  else
    return BFD_ENDIAN_UNKNOWN;
}

Given that that the variable ‘target_byte_order_user ‘ holds the user’s
preference as specified by the “set endian” command, it seems to me that
the code should be

  if (target_byte_order_user != BFD_ENDIAN_UNKNOWN)
    return target_byte_order_user;
 else
    return gdbarch_byte_order (current_gdbarch);

i.e. if the user has explicitly specified the byte order then we use
that, otherwise we use the order determined from the current
architecture.

I can see from the Changelogs, and various pages on the web (like
http://sourceware.org/ml/gdb-patches/2006-11/msg00052.html), that this
function has a history of change – so apologies if I have missed out on
all the reasoning that has led to the current version of the code!

     Regards,

          Richard Stuckey 

Re: gdb 6.8 selected_byte_order function

[Daniel Jacobowitz]

On Wed, Sep 24, 2008 at 11:58:24AM +0100, Richard Stuckey wrote:
> Given that that the variable ‘target_byte_order_user ‘ holds the user’s
> preference as specified by the “set endian” command, it seems to me that
> the code should be
> 
>   if (target_byte_order_user != BFD_ENDIAN_UNKNOWN)
>     return target_byte_order_user;
>  else
>     return gdbarch_byte_order (current_gdbarch);
> 
> i.e. if the user has explicitly specified the byte order then we use
> that, otherwise we use the order determined from the current
> architecture.

This happens at a higher level.  When the user sets the byte order, we
go through set_endian just below.  THe call to gdbarch_update_p
changes current_gdbarch.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb 6.8 selected_byte_order function

[Richard Stuckey]

Ah, I see.  So this function is actually returning the byte order, if
any, selected by the user (hence its name!).

I think that the question I should have asked is why, in function
gdbsim_open in file remote-sim.c, the switch statement has been changed
to call selected_byte_order instead of using TARGET_BYTE_ORDER (which is
#defined to be gdbarch_byte_order (current_gdbarch)) as it did in the
6.6 code?

I suppose this change was because in the 6.6 code there was the comment

  /* Specify the byte order for the target when it is both selectable
     and explicitly specified by the user (not auto detected). */

and the code was not actually doing this: calling gdbarch_byte_order was
using auto-detection in the case that the user had not specified the
byte order.

This change caused a difference in the behaviour of the ARC debugger
when using the built-in simulator: the 6.6. version used a default of
little-endian, whereas in the 6.8 version it is now necessary to issue a
"set endian little" command before the "target sim" command, otherwise a
"Target byte order unspecified" error is given.  Alternatively, using
the "file <program>" command before the "target sim" command, instead of
after it, has the desired effect.

 Thanks for clearing this up for me.

     Richard Stuckey, ARC

Re: gdb 6.8 selected_byte_order function

[Daniel Jacobowitz]

On Wed, Sep 24, 2008 at 02:36:34PM +0100, Richard Stuckey wrote:
> I think that the question I should have asked is why, in function
> gdbsim_open in file remote-sim.c, the switch statement has been changed
> to call selected_byte_order instead of using TARGET_BYTE_ORDER (which is
> #defined to be gdbarch_byte_order (current_gdbarch)) as it did in the
> 6.6 code?

I think you can find a discussion of this on the list archives at
around the time it was made.

> I suppose this change was because in the 6.6 code there was the comment
> 
>   /* Specify the byte order for the target when it is both selectable
>      and explicitly specified by the user (not auto detected). */
> 
> and the code was not actually doing this: calling gdbarch_byte_order was
> using auto-detection in the case that the user had not specified the
> byte order.

That's exactly right.  I believe the problem was that some simulators
do not support -E little and -E big.  They were probably for targets
where switching endianness did not make sense; no need to specify it,
then.

> This change caused a difference in the behaviour of the ARC debugger
> when using the built-in simulator: the 6.6. version used a default of
> little-endian, whereas in the 6.8 version it is now necessary to issue a
> "set endian little" command before the "target sim" command, otherwise a
> "Target byte order unspecified" error is given.  Alternatively, using
> the "file <program>" command before the "target sim" command, instead of
> after it, has the desired effect.

If it's the default you're concerned with, try searching for
WITH_DEFAULT_TARGET_BYTE_ORDER ?

-- 
Daniel Jacobowitz
CodeSourcery