Date: Mon, 24 Jan 2022 10:29:08 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Troubles building world on stable/13 Message-ID: <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> In-Reply-To: <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <FBD31544-6D8F-40DB-BC36-F0B2BBA78A14@yahoo.com> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jan-24, at 10:26, Mark Millard <marklmi@yahoo.com> wrote:
> On 2022-Jan-24, at 08:54, bob prohaska <fbsd@www.zefox.net> wrote:
>=20
>> On Fri, Jan 21, 2022 at 11:14:32PM -0800, Mark Millard wrote:
>>>> On 2022-Jan-20, at 22:00, Mark Millard <marklmi@yahoo.com> wrote:
>>>>=20
>>>=20
>>> It does no good for me since I do not get a failure,
>>> but you might try (instead of exectuing the .sh file)
>>> (I used \'s to split the huge line):
>>>=20
>>> lldb -- "/usr/bin/c++" "-cc1" "-triple" =
"aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" \
>>> "-disable-free" "-disable-llvm-verifier" "-discard-value-names" =
"-main-file-name" "gmock_main.cc" \
>>> "-mrelocation-model" "static" "-mframe-pointer=3Dnon-leaf" =
"-fno-rounding-math" "-mconstructor-aliases" \
>>> "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" =
"-target-abi" "aapcs" \
>>> "-fallow-half-arguments-and-returns" "-debug-info-kind=3Dstandalone" =
"-dwarf-version=3D4" \
>>> "-debugger-tuning=3Dgdb" \
>>> =
"-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletes=
t/gmock_main" \
>>> "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" =
"-Wno-format-y2k" "-W" \
>>> "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" =
"-Wcast-qual" "-Wwrite-strings" "-Wswitch" \
>>> "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" =
"-Wredundant-decls" \
>>> "-Wmissing-variable-declarations" "-Wno-empty-body" =
"-Wno-string-plus-int" "-Wno-unused-const-variable" \
>>> "-Wno-error=3Dunused-but-set-variable" =
"-Wno-deprecated-declarations" "-Wno-deprecated-copy" \
>>> "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \
>>> =
"-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/g=
mock_main" \
>>> "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" =
"-fgnuc-version=3D4.2.1" \
>>> "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" =
"-vectorize-slp" "-faddrsig" \
>>> "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp"
>>>=20
>>> and then "run" at the (lldb) prompt. It might stop and let you
>>> get a backtrace (bt command) in addition to whatever it reports
>>> about the stoppage.
>>=20
>> That seems to have worked, to some extent. Here's the transcript, in =
single-user mode:
>>=20
>> root@pelorus:/usr/src #=20
>> root@pelorus:/usr/src # lldb -- "/usr/bin/c++" "-cc1" "-triple" =
"aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" \
>>> . . .
>>> "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" =
"-vectorize-slp" "-faddrsig" \
>>> "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp"
>> (lldb) target create "/usr/bin/c++"
>>=20
>> Current executable set to '/usr/bin/c++' (aarch64).
>> (lldb) settings set -- target.run-args "-cc1" . . . "c++" =
"gmock_main-f5c28a.cpp"
>> (lldb)=20
>> (lldb) run
>> Process 58516 launched: '/usr/bin/c++' (aarch64)
>> Process 58516 stopped
>> * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid =
address (fault address: 0x1)
>> frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() =
[inlined] getPointer at PointerIntPair.h:59:58
>> 56 =09
>> 57 explicit PointerIntPair(PointerTy PtrVal) { =
initWithPointer(PtrVal); }
>> 58 =09
>> -> 59 PointerTy getPointer() const { return =
Info::getPointer(Value); }
>> 60 =09
>> 61 IntType getInt() const { return =
(IntType)Info::getInt(Value); }
>> 62 =09
>> (lldb) bt
>> * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid =
address (fault address: 0x1)
>> * frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() =
[inlined] getPointer at PointerIntPair.h:59:58
>> frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() =
[inlined] isNull at PointerUnion.h:172:43
>> frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() =
[inlined] empty at TinyPtrVector.h:166:13
>> frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() =
[inlined] empty at ParsedAttr.h:873:40
>> frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at =
SemaDeclAttr.cpp:8449:16
>> frame #5: 0x000000000317e784 =
c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3
>> (lldb)=20
>=20
> To look at the different frames:
>=20
> (lldb) up 1
> (lldb) bt
> . . . (output) . . .
> (lldb) up 1
> (lldb) bt
> . . . (output) . . .
>=20
> and so on until #5 has been displayed.
>=20
>> [repeated bt commands seem to duplicate the same output]
>>=20
>> I can't make much sense of it, but perhaps others can. It does look
>> as if I've somehow corrupted c++. Is there some way to bootstrap
>> past the defect? All the clean targets I've tried (clean, cleandir,=20=
>> cleanworld, rm -rf /usr/obj, cleandepend) seem to have no effect,
>> singly and in combination.=20
>>=20
>> Is it possible to simply delete /usr/src/contrib/llvm-project and=20
>> let git reconstruct it, then force a compiler rebuild somwhow?
>=20
> Using git status should report on any files that do not
> match what is in .git . In my context for main [so: 14]
> that would be:
>=20
> # git -C /usr/main-src status
> . . . (output --if any) . . .
>=20
> You would likely need /usr/src instead.
>=20
> Using git diff would show the specific differences. In my
> context for main [so: 14] that would look like (if no
> differences were found):
>=20
> # git -C /usr/main-src diff
> . . . (output --if any) . . .
>=20
> You would likely need /usr/src .
>=20
> If these do not show anything, the source code is not
> likely to be the problem.
>=20
That last is a bad wording on my part: corrupted source
code is not likely to be the problem.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1CB4EDCD-0998-4363-8CEA-14854EB76FA3>