[parisc-linux] Re:[parisc-linux-cvs] linux-2.6 kyle

[Joel Soete]

> > > > +       struct pt_regs r2 = *r;
> > > 
> > > Is this really wise?  pt_regs is *huge* -- 472 bytes on 32-bit and 688
> > > bytes on 64-bit.
> > > 
> > 
> > Not so bad when you consider we have 16K stack. IIRC, I committed
> > a change to traps.c to not kmalloc but instead put pt_regs on the
> > stack. If x86-64 can get by with an 8K stack, I think we're fine
> > with a 16K stack on 64bit. (Though I really want 8K or 16K page
> > size...)
> 
> It might be better to use memcpy.
> 

Being curious, I compare the 2 unwind.s:
  first with above "struct pt_regs r2 = *r;"
  second after changing it with
     "struct pt_regs r2; memcpy(&r2, r, sizeof(struct pt_regs));"

and there is no diffs (gcc-4.1 32 and 64bit).

I can also read in this file for this unwind_frame_init_from_blocked_task():
--- snip ---
        ldo 424(%r25),%r3
        cmpib,= 0,%r3,.L133
        copy %r3,%r25
        b,l memcpy,%r2
        nop
--- snip ---

Oth, I also made a very small test wit a 'smaller' struct like:
        struct mystruct {
                char                    res_map;
                unsigned long long      pdir_base;
                unsigned int            res_size;
        };

and try:
--- snip ---
        struct mystruct *ms1, *ms2, *ms4;
...
        memcpy(ms4, ms1, sizeof(struct mystruct));
---snip ---

even thought that do the job, even without optimization or -O0, i didn't read
any call to memcpy in s file (reverlty, this same foo.c do well call memcpy if
i replace mystruct with pt_regs)

So it looks like there is a critereria according which gcc decide itself to
use or not memcpy (but I didn't find if there is a way to control this
behaviour as for MIPS with -m(memcpy|no-memcpy)?

 
Cheers,
    Joel

----------
Club Scarlet : Tout le monde gagne! Si vous devenez aujourd'hui Scarlet One grace a un client existant de Scarlet, vous recevez tous les deux un cadeau d'une valeur de 50 euros! Surfez vite sur http://www.clubscarlet.be