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] |
>Of the above, at least the e500 issues I consider to be completely >different; that's dealing with a very particular set of debug info that >only has part of the register. That's a handy thing to solve in the >register cache. Besides, it doesn't play sequential-register-numbering >tricks. That was the whole point - the other numbers are way off in >the 1200 range. > >I'd say the MIPS/i386 issues are also more like e500 than like this >debug info ordering problem that we're talking about here.
(are you sure you're refering to the correct architectures here?)
Absolutely.
I know the e500 situation (limited form of DW_OP_piece for 64-bit registers), and both MIPS/MIPS and x86-64/i386 are trying to expose the same register in multiple ways.
I'm not dismissing the value of the powerful pseudo technique that >you've put together. It's really handy. I just don't think it's the >answer to this problem.
Going back to an earlier point it contains an i386 specific problem to the i386. That way yet another hack doesn't get in the core code. However, the knowledge of needing to handle that case does.
If the choice is: - contain an i386 specific problem to i386 specific code by using a hack
- provide a general, well-defined mechanism that at least now we only need for i386
then I'm all for plan B.
I suppose I could mark both versions of %eax saved in i386's frame_get_saved_regs to fix the immediate problem...
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |