This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: DWARF fix and minimal MMX patch


On Sat, 24 Oct 1998, Robert Lipe wrote:
> Were there testsuite cases for this new functionality written so it can be
> exercised?   Should they be considered along with these patches?

www.bigfoot.com/~hasdi/mmx/


> There was no mmx.h in the submitted patch.

ditto. This is not part of egcs. It is the header you including when
compiling programs with mmx intrinsics.

> [ i386.h ] 
> > +/* MMX regs */
> > +#define FIRST_MMX_REG 17
> > +#define LAST_MMX_REG 24
> > +
> 
> > diff -r -u egcs-19981019/gcc/config/i386/linux.h egcs-mmx/gcc/config/i386/linux.h
> 
> [ in definition of DBX_REGISTER_NUMBER ] 
> > --- egcs-19981019/gcc/config/i386/linux.h	Thu Oct 22 22:54:52 1998
> > +++ egcs-mmx/gcc/config/i386/linux.h	Thu Oct 22 22:29:04 1998
> > @@ -117,6 +117,8 @@
> >   : (n) == 6 ? 5 \
> >   : (n) == 7 ? 4 \
> >   : ((n) >= FIRST_STACK_REG && (n) <= LAST_STACK_REG) ? (n)+3 \
> > + : ((n) >= FIRST_MMX_REG && (n) <= LAST_MMX_REG) ? (n)+4 \
> > + : ((n) == 16) ? (20) \
> >   : (-1))
> 
> Is this really Linux-specific?  Does this mean the emission of debug
> info for MMX regs is Linux-specific or that the patch in general is
> limited to Linux hosts?  A quick grep shows this construct appears many
> other times in i386/ and it's not obvious to me at least if they should
> all be changed in the manner you suggest or not.  Or is this part of the
> dwarf patch you attached?  By smooshing two items into one patch message
> it can be hard to identify which patch is trying to fix which problem.

The MMX portion isn't linux specific. I should work on any pentium-class
platform. I should put this macro in i386.h and other .h files that
modifies this macro. I figure I should start off on linux platform. After
it is accepted, I can then worry about other platforms. There could be
fallacy in my reasoning. 

This macro should be modified if you are integrating the MMX patch. If you
don't, the old expand_dwarf_reg_size code will complain. The new proposed
code does not care and it very faithful to the original intention of the
code. The new code also works for all cases of DWARF register numbering.
The old code only works if the numbering is sequential within and among
register ranges. It may be slow if reg_tree requires memory loading.

The MMX renumbering is most probably wrong but it is enough to keep
expand_builtin_dwarf_reg_size shut up. Feel free to change it to whatever
gdb actually uses. I have trouble searching for this info.

Let me know if I can be of more assistance.

Hasdi




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