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] |
On Apr 1 11:44, Pedro Alves wrote: > On 03/31/2015 07:32 PM, Corinna Vinschen wrote: > > On Mar 31 17:30, Pedro Alves wrote: > >> I think it's bad to hard code > >> the size of the CONTEXT structure, but won't argue further. Patch > >> is OK if you'd really like to apply it as is. > > > > Thanks. But incidentally I retract the patch. It seems we made a > > mistake both, on 32 and 64 bit Cygwin as far as the definition of > > __COPY_CONTEXT_SIZE is concerned. Changing that to sizeof(CONTEXT) now > > would potentially break backward compatibility with all Cygwin versions > > up to today. Oh well. > > Not sure I understand what you mean, but OK. I was a bit unclear, sorry. What I was trying to say is this. Only yesterday in a discussion on IRC it turned out that the definition of __COPY_CONTEXT_SIZE was never identical to sizeof(CONTEXT). The definition of __COPY_CONTEXT_SIZE was based on an underlying datatype, almost, but not quite identical to CONTEXT (i.e. a bug). As a result, __COPY_CONTEXT_SIZE < sizeof(CONTEXT). Worse, Cygwin itself up to the current version 1.7.35 (fixed in the git repo) only stored the leading __COPY_CONTEXT_SIZE bytes of the signal CONTEXT to internal storage for GDB's digestion. Assuming we change GDB now to copy sizeof(CONTEXT), and assuming we're running under a Cygwin <= 1.7.35. GDB would copy random data following the leading __COPY_CONTEXT_SIZE bytes of a CONTEXT to its own CONTEXT. Thus, when later calling SetThreadContext with this data, it would copy random data into the OSes thread context. Which sounds like a really, really bad idea to me. Therefore, for backward compat reasons we should keep this up for a while, until we decide not to support Cygwin versions <= 1.7.35 in GDB any longer. Given that only the leading part of the signal context (actually, basically only the content of Eip/Rip) is really important here, nothing much is lost. I hope I could clarify the situation. If you have another idea how we could handle this a bit..., well, more correct or something, please do tell. > > Sorry for the longish discussion for nothing :( > > Sounds like it wasn't for nothing then. Indeed :) Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpZXEN5Is1cL.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |