| delorie.com/archives/browse.cgi | search |
On Sep 13 12:47, John Carey wrote: > On Sep 11 03:30, Corinna Vinschen: > > Can't we find Cwd by scanning the .data segment of ntdll.h for the > > address we inferred from the Params.CurrentDirectoryName.Buffer value? >=20 > Nice; that might work. But there would need to be some kind of rule > to pick a winner among multiple matching words, in case by coincidence > some other non-pointer word just happens to have the same bit pattern. > I can see two alternatives for the multiple-match case: >=20 > 1. Code scanning, as suggested earlier. There would need to be a > unit test of the code scanner itself so that incompatible changes to > ntdll.dll could be detected deterministically, instead of only after > a multiple-match coincidence. >=20 > 2. Call SetCurrentDirectory() and recheck the previously-matching > addresses to see which one matches the new value. Place some limit > (like 4) on the number of such retries, in case some new version of > ntdll.dll intentionally duplicates the pointer every time. > (Not sure what to do in that case; fall back to code scanning?) Sorry, I just realized that while Cygwin might do all this to find &Cwd, it will not work for &CwdCS. There must be plenty of critical sections floating around. Still, reducing the number of addresses that must be discovered by code scanning might still help future-proof things. -- John -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |