Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Mar 2021 12:39:05 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        jrtc27@freebsd.org, dev-commits-src-main@freebsd.org, cognet@ci0.org
Cc:        John Baldwin <jhb@freebsd.org>
Subject:   Re: git: c328f64d8107 - main - arm64: Fix COMPAT_FREEBSD32.
Message-ID:  <70652D35-2738-4E75-901C-9997869CE8D6@yahoo.com>
References:  <70652D35-2738-4E75-901C-9997869CE8D6.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jessica Clarke jrtc27 at freebsd.org wrote on
Wed Mar 10 18:36:39 UTC 2021 :

> On 10 Mar 2021, at 18:07, Olivier Houchard <cognet at FreeBSD.org> =
wrote:
> >=20
> > The branch main has been updated by cognet:
> >=20
> > URL: =
https://cgit.FreeBSD.org/src/commit/?id=3Dc328f64d81079bad5064c8a387883df5=
0ab5aaed
> >=20
> > commit c328f64d81079bad5064c8a387883df50ab5aaed
> > Author:     Olivier Houchard <cognet at FreeBSD.org>
> > AuthorDate: 2021-03-10 18:01:41 +0000
> > Commit:     Olivier Houchard <cognet at FreeBSD.org>
> > CommitDate: 2021-03-10 18:06:42 +0000
> >=20
> >    arm64: Fix COMPAT_FREEBSD32.
> >=20
> >    The ENTRY() macro was modified by commit
> >    28d945204ea1014d7de6906af8470ed8b3311335 to add an optional NOP =
instruction
> >    at the beginning of the function. It is of course an arm64 =
instruction, so
> >    unsuitable for the 32bits sigcode. So just use EENTRY() instead =
for
> >    aarch32_sigcode. This should fix receiving signals when running =
32bits
> >    binaries on FreeBSD/arm64.
>=20
> Hmm, that's a good point, does the extra nop for the AArch64 sigcode
> cause issues for gdb detecting it?
>=20
> Perhaps we should upstream CheriBSD's SIGCODE macros?..

I'll note that, in my reports on the lists about aarch64 having
problems with armv7 port building failures, I used lldb because
gdb did not report backtraces beyond #0 but lldb did report
more complete backtraces.

However, for lldb part of my notes were a report of a
potential missing frame as well:

QUOTE
I'll note that when I looked at detail as the assembler level
it appeared that there was a frame not shown between #0 and #1
in lldb's output: Frame #1 "->" was indicating the instruction
after a simple bl to a not-shown subroutine.

For building textproc/libxslt :
(jobserver_acquire not shown between #0 and #1)

(lldb) bt
* thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV
 * frame #0: 0xffffe190
   frame #1: 0x0003b5f8 gmake`new_job(file=3D<unavailable>) at =
job.c:1870:21
   frame #2: 0x0002db80 gmake`execute_file_commands(file=3D<unavailable>) =
at commands.c:476:3 [artificial]
   frame #3: 0x00049acc gmake`update_file [inlined] =
remake_file(file=3D0x400a9700) at remake.c:1234:11
   frame #4: 0x00049a84 gmake`update_file [inlined] =
update_file_1(file=3D<unavailable>, depth=3D6) at remake.c:835
   frame #5: 0x000494ec gmake`update_file(file=3D<unavailable>, =
depth=3D<unavailable>) at remake.c:336
   frame #6: 0x0004b08c gmake`check_dep(file=3D0x400a9700, =
depth=3D<unavailable>, this_mtime=3D1, must_make_ptr=3D0xffffc4ac) at =
remake.c:1024:20
   frame #7: 0x00049074 gmake`update_file at remake.c:572:17
   frame #8: 0x00048b80 gmake`update_file(file=3D<unavailable>, =
depth=3D<unavailable>) at remake.c:336
   frame #9: 0x0004b08c gmake`check_dep(file=3D0x400a9400, =
depth=3D<unavailable>, this_mtime=3D1, must_make_ptr=3D0xffffc564) at =
remake.c:1024:20
   frame #10: 0x00049074 gmake`update_file at remake.c:572:17
   frame #11: 0x00048b80 gmake`update_file(file=3D<unavailable>, =
depth=3D<unavailable>) at remake.c:336
   frame #12: 0x0004b08c gmake`check_dep(file=3D0x400a8f20, =
depth=3D<unavailable>, this_mtime=3D1, must_make_ptr=3D0xffffc61c) at =
remake.c:1024:20
   frame #13: 0x00049074 gmake`update_file at remake.c:572:17
   frame #14: 0x00048b80 gmake`update_file(file=3D<unavailable>, =
depth=3D<unavailable>) at remake.c:336
   frame #15: 0x000487e0 gmake`update_goal_chain(goaldeps=3D<unavailable>)=
 at remake.c:151:22
   frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd470, =
envp=3D0xffffffff) at main.c:2589:13
   frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D<unavailable>, =
env=3D<unavailable>, ps_strings=3D<unavailable>, obj=3D0x400c4004, =
cleanup=3D0x40091aa0) at crt1_c.c:92:7

-> 1870	        got_token =3D jobserver_acquire (waiting_jobs !=3D =
NULL);

   0x3b5f4 <+1288>: bl     0x50078                   ; jobserver_acquire =
at posixos.c:265
->  0x3b5f8 <+1292>: cmp    r0, #1
END QUOTE

The backtrace example above did not show
jobserver_acquire as having a frame.

The original note had more examples: all the
example process failures had an apparently
missing frame in the lldb backtrace.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70652D35-2738-4E75-901C-9997869CE8D6>