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] MIPS: Avoid breakpoints in branch delay slots


> Well, 64-bit immediates may be truncated, unless we have 64-bit BFD 
> support, due to the lack of a 64-bit integer data type I believe.

OK, so that was the goal.

>  I agree that #ifdefs scattered throughout code are ugly and best avoided, 
> so I have rewritten this piece so as to derive the shift count from the 
> width of the type.  The result may not be the prettiest piece of code I 
> have ever seen, but there you go.  As I say, it may be more reasonable to 
> consider deprecating pre-C9x compilers, or at least those that do not 
> provide a "long long" alternative.

I am having doubts again, but I think we do require C90 to compile GDB.
It's C99 that is not mandatory yet (hence the use of gnulib for some of
the C99 headers). Based on that, can we consider that we're always going
to have a 64bit "long long"?

> 2011-12-07  Chris Dearman  <chris@mips.com>
>             Nathan Froyd  <froydnj@codesourcery.com>
>             Maciej W. Rozycki  <macro@codesourcery.com>
> 
> 	gdb/
> 	* mips-tdep.c (mips32_instruction_has_delay_slot): New function.
> 	(mips16_instruction_has_delay_slot): Likewise.
> 	(mips_segment_boundary): Likewise.
> 	(mips_adjust_breakpoint_address): Likewise.
> 	(mips_gdbarch_init): Use mips_adjust_breakpoint_address.

The code looks good to me. I will let you decide which version you
think is going to be better to maintain. I was just afraid that you
needed to know what the *target* address size was, in which case the
define would have been the wrong solution.

Thanks for the detailed explanations...

-- 
Joel


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