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: patch for printing 64-bit values in i386 registers; STABS format



 - stabs would have to be modified (if we did this fixup in each and
every debug reader, instead of in read_var_value and friends; I see
good arguments both ways)

It would hopefully be a shared function that those debug readers could call. The important thing is that the core code only knows about one mechanism.


>This is one of the intended purposes of this mechanism, and as I

>>indicated, is needed by MIPS. Being able to project an arbitrary [debug >>info] view of the registers onto the raw register buffer.
>>
>>BTW, what happens when there is an attempt to write a long long value? >>GDB again assumes that it can write to contigious registers - the reason >>why REGISTER_BYTE can't be killed.

>
>
>That ugliness could go away too with Mark's introduced method.  GDB
>could be fixed to find the next register properly.


GDB also uses it to encode offsets into a register. It also does not help the MIPS where the debug register does need to be projected into the raw registers. Why have add more mechanisms when the existing one is sufficient. Focus the effort on fixing the real problem.


BTW, my comment about no names was wrong. They can be named, that restriction should have been removed by the introduction of reggroups.


Well, in that case I guess it would work. Let's do it?

It still feels much more like a hack to me than Mark's approach; I'll
just quietly disagree I suppose.

Hmm, I think it will be needed anyway, what happens when the user is debugging an i386 mode function (with 32 bit register based long long debug info) on an x86-64 target? That's the MIPS problem, and it needs that projection(1).


Also, the next_regnum method assumes that all debug infos use the same register sequencing.

A word of caution though, the projection, at the register level works. Frame's might need tweaking. The alternative is to start out with deprecated_next_regnum so that it is clear where this stands.

Andrew

(1) dwarf2 debug info makes certain assumptions about the size of registers



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