On 1/4/23 7:59 PM, Jessica Clarke wrote:
On 5 Jan 2023, at 03:50, Cy Schubert <[email protected]> wrote:
In message <[email protected]>, John Baldwin
writ
es:
The branch main has been updated by jhb:
URL: https://cgit.FreeBSD.org/src/commit/?id=b069d3e0193121ff6de348f68c7ce93e
e61e5e2f
commit b069d3e0193121ff6de348f68c7ce93ee61e5e2f
Author: John Baldwin <[email protected]>
AuthorDate: 2023-01-04 22:55:00 +0000
Commit: John Baldwin <[email protected]>
CommitDate: 2023-01-04 22:55:00 +0000
rtld: Revert "When loading dso without PT_GNU_STACK phdr, only call"
After the removal of ia64 and sparc64, all current architectures
support executable stacks at an architectural level.
This reverts commit 1290d38ac50b3afa7e5781d9d97346a1042c736c.
I tried git log as follows in two independent repos, my "prod" repo and the
working repo I commit from:
slippy$ git log 1290d38ac50b3afa7e5781d9d97346a1042c736c
fatal: bad object 1290d38ac50b3afa7e5781d9d97346a1042c736c
slippy$
Could there be some corruption somewhere? Do other people have the same
result as I do when they run git log against that hash? Or are my repos
corrupted?
When I run git log and search for the string "When loading dso without
PT_GNU_STACK phdr, only call", I find the following, suggesting that the
svn2git process may have resulted in different hashes in different repos
used by different people.
commit cb38d4941c45e3c72c4b5b3fad87d297d950cf53
Author: Konstantin Belousov <[email protected]>
AuthorDate: Tue Jan 25 21:12:31 2011 +0000
Commit: Konstantin Belousov <[email protected]>
CommitDate: Tue Jan 25 21:12:31 2011 +0000
When loading dso without PT_GNU_STACK phdr, only call
__pthread_map_stacks_exec() on architectures that allow executable
stacks.
Reported and tested by: marcel (ia64)
Notes:
svn path=/head/; revision=217851
BTW, our GH read-only mirror has the same hash as above suggesting that
jhb's repo may not be in sync with others with regard to svn2git generated
commits?
Or, does this point to a deeper problem with inconsistent repos or some
other svn2git inconsistency somewhere?
It’s the hash from the old GitHub mirror that's now freebsd/freebsd-legacy.
Interesting, that is the hash I got from git blame for some reason. I might
have done the blame in CheriBSD though which has a complicated history where
it merged commits from the old hashes up to a point when the new hashes
were published, then CheriBSD has a special merge commit to join the old and
new histories before merging the new hashes from that point forwards.
--
John Baldwin
