This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Don't allow setting register in non-innermost frame


On 08/21/2012 04:19 AM, Doug Evans wrote:
fwiw, I've been able to work around corrupt, or otherwise not
completely useful, core files by setting registers in non-innermost
frames.
Granted, I knew what was happening underneath the covers, so to speak,
and I could have done things differently, but I like this capability.


Yeah, it is convenient, but sometimes it is misleading. People who are clear on what is happening underneath can modify the frame/memory directly where the registers are saved.


If gdb had started out disallowing changing registers in non-innermost
frames, we mightn't be thinking of restricting it now.
"It's easier to relax restrictions than it is to impose them after the fact."

Even if the fact is not clear or misleading sometimes?


I'd like to hear more justification for this change.

Unfortunately, I don't have extra justification here. I am writing a new MI notification when register is modified by 'set $reg=FOO' in console, similar to the patches on 'command parameter change' notification. When the register is modified in innermost frame, a MI notification (with frame info) can be sent to MI frontend, and frontend can update its register contents, such as "register view". However, if register is modified in non-innermost frame, the notification is not useful to frontend. Then, I started to think of the meaning of 'setting register in non-innermost frame', and proposed this change finally.


--
Yao


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