https://sourceware.org/bugzilla/show_bug.cgi?id=22960
--- Comment #5 from Saagar Jha <saagar at saagarjha dot com> ---
(In reply to Ray Seyfarth from comment #2)
Post by thor.lilei at gmail dot comSame problem with me.
I have to wonder how Apple gets lldb to work with no problems. It appears
to not be codesigned nor setuid/gid or anything special. There is an option
which works which Apple should share with the open source community. They
have wasted a lot of my time.
LLDB is signed with Apple's certificate:
$ codesign -dvv `xcrun -find lldb`
Executable=/Applications/Xcode-beta.app/Contents/Developer/usr/bin/lldb
Identifier=com.apple.lldb
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=622 flags=0x0(none) hashes=15+2 location=embedded
Signature size=4535
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=6
TeamIdentifier=59GAB85EFG
Sealed Resources=none
Internal requirements count=1 size=64
--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
(In reply to Saagar Jha from comment #4)
Post by thor.lilei at gmail dot com$ git bisect run ../gdb-bisect.sh
running /Users/saagarjha/Git/bisect-test.sh
[Snip]
f6ac5f3d63e03a81c4ff3749aba234961cc9090e is the first bad commit
commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e
Date: Thu May 3 00:37:22 2018 +0100
Convert struct target_ops to C++
[Snip]
bisect run success
That commit can't be the culprit for the issue reported in this bug,
because that commit is recent, it is in master only, not in 8.1.
It if caused some breakage, it's something else. A separate bug report
would have been better.
Post by thor.lilei at gmail dot comCould someone confirm this for me? Commits before this one can successfully
follow the debuggee to completion without incident, but the ones after and
including this one crash with a null pointer dereference in
gdb`push_target(struct target_ops *) at target.c:653. From a cursory glance,
it seems a little fishy that darwin-nat.c doesn't have any sort of
add_target call in it,
The add_target call is in i386-darwin-nat.c:_initialize_i386_darwin_nat
add_inf_child_target (&darwin_target);
Post by thor.lilei at gmail dot combut I can't understand the code in the C/C++
frankenstein state it's in right now,
Yeah. Anything in particular you'd like to point out?
Post by thor.lilei at gmail dot comso I wasn't able to come up with a
fix. (I did find a bunch of undefined behavior being hit, though, which I
*do* have patches for. Let me know if you're curious in seeing them.)
Yes please. If you could contribute fixes, it'd be awesome:
https://sourceware.org/gdb/wiki/ContributionChecklist
In case it isn't obvious, the macOS port is in real need of someone motivated
to maintain it. I'm afraid that none of the day-to-day maintainers uses macOS,
AFAIK. You can see it as an opportunity.
Post by thor.lilei at gmail dot com<rant>
Just as a FYI, confirming this particular commit took well over two days and
testing over two hundred revisions, which is something that I find as an
outside observer to be truly horrible.
Wow. Sorry about that. Two hundred revisions sounds way too many for a git
bisect? How could that have happened?
Post by thor.lilei at gmail dot comDoes GDB have *no* automated testing
or continuous integration whatsoever?
It does, see <https://sourceware.org/gdb/wiki/BuildBot>. The problem is nobody
ever contributed a macOS buildslave.
Post by thor.lilei at gmail dot comPutting aside the fact that any such
infrastructure would catch simple bugs like this one, which are easy to
reproduce, it would have also made my life bisecting a lot easier. Many
intermediate commits are broken, as in they *literally don't build on
macOS*, because someone forgot a header file or messed up a Makefile. Others
dereference null pointers or overflow ints during startup, which really
threw off my bisect script with false positives: I had to restart the bisect
from the beginning at least half a dozen times because it homed in on the
wrong bug.
:-( Sound like maybe "git bisect skip" would have helped?
Post by thor.lilei at gmail dot comI'm aghast that it's possible for such clearly broken patches to
land in the master branch. I do apologize for the vitriolic tone here, but
I'm extremely frustrated at the amount of time I had to spend finding this
when it should have been a rather trivial task. I do hope none of you take
it personally–but if you're looking for things to improve, this is one thing
I think you should focus on.
Nope, sorry. The thing to improve is _getting someone that actually cares
about the port to step up and help maintain it_. That could be you.
Otherwise, I fear that at some point, the port will just end up deprecated and
removed.
--
You are receiving this mail because:
You are on the CC list for the bug.