This is the mail archive of the gdb-patches@sources.redhat.com 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: Signal Trampoline Frames


   Date: Wed, 24 Mar 2004 19:26:09 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > Andrew,
   > 
   > It's probably too late now, but I have the feeling this new
   > tramp-frame.c is not generic enough.  It assumes fixed-length
   > instructions (which makes it unsuitable for IA-32 and AMD64)

   I didn't forget IA-32, I figured that it is always little endian so a 
   sequence of one byte "insns" would work.

Ah, that would probably work :-).

    > and uses
   > the arbitrary number 8 for the number of instructions (which makes it
   > not quite suitable for SPARC).

   I'm assuming people will increase it (It's like the arbitrary number 16 
   for the largest possible size of an instruction).

OK.  Although you must realize that for SPARC we might need to
increase it to 80 or so.  Then it makes more sense to check only for a
small number of key instructions I think.

    > The whole thing seems a bit
   > over-engineered to me :-(.

   In what way?

   I wrote it after churn out 4 almost identical signal trampolines - so it 
   works for one type but not for others.  You also haven't seen my test 
   cases :-)

My experience is that there is too much variation for a
one-size-fits-all trampoline recognition function.  I was under the
impression that there were only two cases where this could be used.
Turns out I'm wrong.  I still think we run the risk of
over-engineering this by adding to much knobs if we try to make it
work for too many slightly different signal tramps.

Mark


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