* san_ignore_object not found at link time @ 2020-08-01 14:10 T.V Raman 2020-08-01 14:37 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: T.V Raman @ 2020-08-01 14:10 UTC (permalink / raw) To: emacs-devel Building emacs from head breaks like so: /usr/bin/ld: emacs-module.o: in function `Fmodule_load': /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object' collect2: error: ld returned 1 exit status make: *** [Makefile:650: temacs] Error 1 -- -- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 14:10 san_ignore_object not found at link time T.V Raman @ 2020-08-01 14:37 ` Eli Zaretskii 2020-08-01 14:45 ` T.V Raman 2020-08-01 14:45 ` Eli Zaretskii 0 siblings, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 14:37 UTC (permalink / raw) To: T.V Raman; +Cc: emacs-devel > From: "T.V Raman" <raman@google.com> > Date: Sat, 1 Aug 2020 07:10:14 -0700 (PDT) > > Building emacs from head breaks like so: > > /usr/bin/ld: emacs-module.o: in function `Fmodule_load': > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object' > collect2: error: ld returned 1 exit status > make: *** [Makefile:650: temacs] Error 1 Please try again, I think I fixed that a few minutes ago. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 14:37 ` Eli Zaretskii @ 2020-08-01 14:45 ` T.V Raman 2020-08-01 14:45 ` Eli Zaretskii 1 sibling, 0 replies; 23+ messages in thread From: T.V Raman @ 2020-08-01 14:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel may not have landed yet, git pull says current branch master is up to date -- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 14:37 ` Eli Zaretskii 2020-08-01 14:45 ` T.V Raman @ 2020-08-01 14:45 ` Eli Zaretskii 2020-08-01 15:02 ` Philipp Stephani ` (2 more replies) 1 sibling, 3 replies; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 14:45 UTC (permalink / raw) To: raman, Philipp Stephani; +Cc: emacs-devel > Date: Sat, 01 Aug 2020 17:37:56 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > From: "T.V Raman" <raman@google.com> > > Date: Sat, 1 Aug 2020 07:10:14 -0700 (PDT) > > > > Building emacs from head breaks like so: > > > > /usr/bin/ld: emacs-module.o: in function `Fmodule_load': > > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object' > > collect2: error: ld returned 1 exit status > > make: *** [Makefile:650: temacs] Error 1 > > Please try again, I think I fixed that a few minutes ago. Actually, I fixed a different problem, sorry. Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your src/config.h? If so, it sounds like the configure-time test for this functionality is incomplete. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 14:45 ` Eli Zaretskii @ 2020-08-01 15:02 ` Philipp Stephani 2020-08-01 15:38 ` Alan Third 2020-08-01 16:43 ` T.V Raman 2 siblings, 0 replies; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 15:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Emacs developers, raman Am Sa., 1. Aug. 2020 um 16:45 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > Date: Sat, 01 Aug 2020 17:37:56 +0300 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: emacs-devel@gnu.org > > > > > From: "T.V Raman" <raman@google.com> > > > Date: Sat, 1 Aug 2020 07:10:14 -0700 (PDT) > > > > > > Building emacs from head breaks like so: > > > > > > /usr/bin/ld: emacs-module.o: in function `Fmodule_load': > > > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object' > > > collect2: error: ld returned 1 exit status > > > make: *** [Makefile:650: temacs] Error 1 > > > > Please try again, I think I fixed that a few minutes ago. > > Actually, I fixed a different problem, sorry. > > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your > src/config.h? If so, it sounds like the configure-time test for this > functionality is incomplete. Yeah, maybe we should also check for the function itself to be present. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 14:45 ` Eli Zaretskii 2020-08-01 15:02 ` Philipp Stephani @ 2020-08-01 15:38 ` Alan Third 2020-08-01 17:32 ` Philipp Stephani 2020-08-01 16:43 ` T.V Raman 2 siblings, 1 reply; 23+ messages in thread From: Alan Third @ 2020-08-01 15:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Philipp Stephani, emacs-devel, raman On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote: > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your > src/config.h? If so, it sounds like the configure-time test for this > functionality is incomplete. I'm getting a similar error: CCLD temacs Undefined symbols for architecture x86_64: "___lsan_ignore_object", referenced from: _enlarge_buffer_text in buffer.o _Fmake_variable_buffer_local in data.o _Fmake_local_variable in data.o _Fmodule_load in emacs-module.o _initialize_environment in emacs-module.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [temacs] Error 1 make: *** [src] Error 2 # grep SANITIZER src/config.h #define HAVE_SANITIZER_LSAN_INTERFACE_H 1 -- Alan Third ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 15:38 ` Alan Third @ 2020-08-01 17:32 ` Philipp Stephani 2020-08-01 17:51 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 17:32 UTC (permalink / raw) To: Alan Third, Eli Zaretskii, raman, Philipp Stephani, Emacs developers Am Sa., 1. Aug. 2020 um 17:38 Uhr schrieb Alan Third <alan@idiocy.org>: > > On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote: > > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your > > src/config.h? If so, it sounds like the configure-time test for this > > functionality is incomplete. > > I'm getting a similar error: > > CCLD temacs > Undefined symbols for architecture x86_64: > "___lsan_ignore_object", referenced from: > _enlarge_buffer_text in buffer.o > _Fmake_variable_buffer_local in data.o > _Fmake_local_variable in data.o > _Fmodule_load in emacs-module.o > _initialize_environment in emacs-module.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[1]: *** [temacs] Error 1 > make: *** [src] Error 2 > > # grep SANITIZER src/config.h > #define HAVE_SANITIZER_LSAN_INTERFACE_H 1 I've pushed commit 06310cf912 which should hopefully fix this, could you please try again? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 17:32 ` Philipp Stephani @ 2020-08-01 17:51 ` Eli Zaretskii 2020-08-01 18:02 ` Eli Zaretskii 2020-08-01 18:29 ` Philipp Stephani 2020-08-01 18:09 ` T.V Raman 2020-08-01 18:13 ` Alan Third 2 siblings, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 17:51 UTC (permalink / raw) To: Philipp Stephani; +Cc: alan, emacs-devel, p.stephani2, raman > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 1 Aug 2020 19:32:40 +0200 > > I've pushed commit 06310cf912 which should hopefully fix this, could > you please try again? I now get a compilation warning: alloc.c: In function 'mark_maybe_object': alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) | ^ This is a 32-bit build --with-wide-int, in case it matters, where EMACS_INT is a 64-bit data type. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 17:51 ` Eli Zaretskii @ 2020-08-01 18:02 ` Eli Zaretskii 2020-08-01 18:33 ` Philipp Stephani 2020-08-01 18:52 ` Andreas Schwab 2020-08-01 18:29 ` Philipp Stephani 1 sibling, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 18:02 UTC (permalink / raw) To: Paul Eggert; +Cc: p.stephani2, raman, alan, emacs-devel > Date: Sat, 01 Aug 2020 20:51:42 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: alan@idiocy.org, emacs-devel@gnu.org, p.stephani2@gmail.com, > raman@google.com > > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > | ^ > > This is a 32-bit build --with-wide-int, in case it matters, where > EMACS_INT is a 64-bit data type. Btw, I'm probably missing something, because I don't understand how XLP in its current definition can work in a --with-wide-int build, where the size of a Lisp_Object is wider than both intptr_t and a 'void *'. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 18:02 ` Eli Zaretskii @ 2020-08-01 18:33 ` Philipp Stephani 2020-08-01 18:52 ` Andreas Schwab 1 sibling, 0 replies; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 18:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, Paul Eggert, raman, Emacs developers Am Sa., 1. Aug. 2020 um 20:03 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > Date: Sat, 01 Aug 2020 20:51:42 +0300 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: alan@idiocy.org, emacs-devel@gnu.org, p.stephani2@gmail.com, > > raman@google.com > > > > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > > | ^ > > > > This is a 32-bit build --with-wide-int, in case it matters, where > > EMACS_INT is a 64-bit data type. > > Btw, I'm probably missing something, because I don't understand how > XLP in its current definition can work in a --with-wide-int build, > where the size of a Lisp_Object is wider than both intptr_t and a > 'void *'. This is somewhat subtle, but I think in this case it works because the function bails out for the int types, and all other types are tagged pointers. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 18:02 ` Eli Zaretskii 2020-08-01 18:33 ` Philipp Stephani @ 2020-08-01 18:52 ` Andreas Schwab 1 sibling, 0 replies; 23+ messages in thread From: Andreas Schwab @ 2020-08-01 18:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: p.stephani2, Paul Eggert, emacs-devel, alan, raman On Aug 01 2020, Eli Zaretskii wrote: >> Date: Sat, 01 Aug 2020 20:51:42 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: alan@idiocy.org, emacs-devel@gnu.org, p.stephani2@gmail.com, >> raman@google.com >> >> 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) >> | ^ >> >> This is a 32-bit build --with-wide-int, in case it matters, where >> EMACS_INT is a 64-bit data type. > > Btw, I'm probably missing something, because I don't understand how > XLP in its current definition can work in a --with-wide-int build, > where the size of a Lisp_Object is wider than both intptr_t and a > 'void *'. This has nothing to do with XLP. If you add a wide integer to a pointer you still have a pointer, whereas if you add a wide integer to a pointer converted to intptr_t, the result is of the widened type. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 17:51 ` Eli Zaretskii 2020-08-01 18:02 ` Eli Zaretskii @ 2020-08-01 18:29 ` Philipp Stephani 2020-08-01 18:32 ` Eli Zaretskii 1 sibling, 1 reply; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 18:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, Emacs developers, raman Am Sa., 1. Aug. 2020 um 19:51 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sat, 1 Aug 2020 19:32:40 +0200 > > > > I've pushed commit 06310cf912 which should hopefully fix this, could > > you please try again? > > I now get a compilation warning: > > alloc.c: In function 'mark_maybe_object': > alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > | ^ > > This is a 32-bit build --with-wide-int, in case it matters, where > EMACS_INT is a 64-bit data type. This is due to the unrelated commit a2323c7ccb. (I just happened to push both commits at the same time.) It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so that the entire expression gets widened to a 64-bit number. However, since it's cast back to a pointer, the value has to fit in 32 bits. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 18:29 ` Philipp Stephani @ 2020-08-01 18:32 ` Eli Zaretskii 2020-08-01 18:35 ` Philipp Stephani 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 18:32 UTC (permalink / raw) To: Philipp Stephani; +Cc: alan, emacs-devel, raman > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 1 Aug 2020 20:29:29 +0200 > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > Emacs developers <emacs-devel@gnu.org> > > > alloc.c: In function 'mark_maybe_object': > > alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > > | ^ > > > > This is a 32-bit build --with-wide-int, in case it matters, where > > EMACS_INT is a 64-bit data type. > > This is due to the unrelated commit a2323c7ccb. (I just happened to > push both commits at the same time.) > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so > that the entire expression gets widened to a 64-bit number. However, > since it's cast back to a pointer, the value has to fit in 32 bits. The pointer is there, you just cannot safely extract it by casting to a narrower data type. You need to explicitly mask the MSBs by shifting or some other bit fiddling. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 18:32 ` Eli Zaretskii @ 2020-08-01 18:35 ` Philipp Stephani 2020-08-01 19:17 ` Philipp Stephani 0 siblings, 1 reply; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 18:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, Emacs developers, raman Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sat, 1 Aug 2020 20:29:29 +0200 > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > > Emacs developers <emacs-devel@gnu.org> > > > > > alloc.c: In function 'mark_maybe_object': > > > alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > > > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > > > | ^ > > > > > > This is a 32-bit build --with-wide-int, in case it matters, where > > > EMACS_INT is a 64-bit data type. > > > > This is due to the unrelated commit a2323c7ccb. (I just happened to > > push both commits at the same time.) > > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so > > that the entire expression gets widened to a 64-bit number. However, > > since it's cast back to a pointer, the value has to fit in 32 bits. > > The pointer is there, you just cannot safely extract it by casting to > a narrower data type. You need to explicitly mask the MSBs by > shifting or some other bit fiddling. IIUC casting between unsigned integer types is guaranteed to have the same effect. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 18:35 ` Philipp Stephani @ 2020-08-01 19:17 ` Philipp Stephani 2020-08-01 19:21 ` Philipp Stephani 2020-08-01 19:21 ` Eli Zaretskii 0 siblings, 2 replies; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 19:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, Emacs developers, raman Am Sa., 1. Aug. 2020 um 20:35 Uhr schrieb Philipp Stephani <p.stephani2@gmail.com>: > > Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Sat, 1 Aug 2020 20:29:29 +0200 > > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > > > Emacs developers <emacs-devel@gnu.org> > > > > > > > alloc.c: In function 'mark_maybe_object': > > > > alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > > > > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > > > > | ^ > > > > > > > > This is a 32-bit build --with-wide-int, in case it matters, where > > > > EMACS_INT is a 64-bit data type. > > > > > > This is due to the unrelated commit a2323c7ccb. (I just happened to > > > push both commits at the same time.) > > > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so > > > that the entire expression gets widened to a 64-bit number. However, > > > since it's cast back to a pointer, the value has to fit in 32 bits. > > > > The pointer is there, you just cannot safely extract it by casting to > > a narrower data type. You need to explicitly mask the MSBs by > > shifting or some other bit fiddling. > > IIUC casting between unsigned integer types is guaranteed to have the > same effect. I've now used INT_SUBTRACT_WRAPV, which should guarantee that the offset is defined and fits within an intptr_t. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 19:17 ` Philipp Stephani @ 2020-08-01 19:21 ` Philipp Stephani 2020-08-01 19:21 ` Eli Zaretskii 1 sibling, 0 replies; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 19:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, Emacs developers, raman Am Sa., 1. Aug. 2020 um 21:17 Uhr schrieb Philipp Stephani <p.stephani2@gmail.com>: > > Am Sa., 1. Aug. 2020 um 20:35 Uhr schrieb Philipp Stephani > <p.stephani2@gmail.com>: > > > > Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > > Date: Sat, 1 Aug 2020 20:29:29 +0200 > > > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > > > > Emacs developers <emacs-devel@gnu.org> > > > > > > > > > alloc.c: In function 'mark_maybe_object': > > > > > alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > > > > > 4641 | void *po = (char *) ((intptr_t) (char *) XLP (obj) > > > > > | ^ > > > > > > > > > > This is a 32-bit build --with-wide-int, in case it matters, where > > > > > EMACS_INT is a 64-bit data type. > > > > > > > > This is due to the unrelated commit a2323c7ccb. (I just happened to > > > > push both commits at the same time.) > > > > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so > > > > that the entire expression gets widened to a 64-bit number. However, > > > > since it's cast back to a pointer, the value has to fit in 32 bits. > > > > > > The pointer is there, you just cannot safely extract it by casting to > > > a narrower data type. You need to explicitly mask the MSBs by > > > shifting or some other bit fiddling. > > > > IIUC casting between unsigned integer types is guaranteed to have the > > same effect. > > I've now used INT_SUBTRACT_WRAPV, which should guarantee that the > offset is defined and fits within an intptr_t. However, I guess when using wide ints *and* MSB tags the subtraction might overflow, so maybe the assertion should be conditioned on that case. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 19:17 ` Philipp Stephani 2020-08-01 19:21 ` Philipp Stephani @ 2020-08-01 19:21 ` Eli Zaretskii 2020-08-01 19:26 ` Eli Zaretskii 1 sibling, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 19:21 UTC (permalink / raw) To: Philipp Stephani; +Cc: alan, emacs-devel, raman > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 1 Aug 2020 21:17:05 +0200 > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > Emacs developers <emacs-devel@gnu.org> > > I've now used INT_SUBTRACT_WRAPV, which should guarantee that the > offset is defined and fits within an intptr_t. Thanks, the warning is gone now. Though I still don't like the code there, it feels wrong even if it isn't. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 19:21 ` Eli Zaretskii @ 2020-08-01 19:26 ` Eli Zaretskii 2020-08-01 19:40 ` Philipp Stephani 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2020-08-01 19:26 UTC (permalink / raw) To: p.stephani2; +Cc: alan, raman, emacs-devel > Date: Sat, 01 Aug 2020 22:21:24 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: alan@idiocy.org, emacs-devel@gnu.org, raman@google.com > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sat, 1 Aug 2020 21:17:05 +0200 > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > > Emacs developers <emacs-devel@gnu.org> > > > > I've now used INT_SUBTRACT_WRAPV, which should guarantee that the > > offset is defined and fits within an intptr_t. > > Thanks, the warning is gone now. Though I still don't like the code > there, it feels wrong even if it isn't. I spoke too soon: it compiles, but that hits assertion violation while loading: CCLD temacs.exe /bin/mkdir -p ../etc make -C ../lisp update-subdirs make[2]: Entering directory `/d/gnu/git/emacs/trunk/lisp' make[2]: Leaving directory `/d/gnu/git/emacs/trunk/lisp' cp -f temacs.exe bootstrap-emacs.exe rm -f bootstrap-emacs.pdmp ./temacs --batch -l loadup --temacs=pbootstrap Loading loadup.el (source)... dump mode: pbootstrap Using load-path (d:/gnu/git/emacs/trunk/lisp d:/gnu/git/emacs/trunk/lisp/emacs-lisp d:/gnu/git/emacs/trunk/lisp/progmodes d:/gnu/git/emacs/trunk/lisp/language d:/gnu/git/emacs/trunk/lisp/international d:/gnu/git/emacs/trunk/lisp/textmodes d:/gnu/git/emacs/trunk/lisp/vc) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... Loading version... alloc.c:4646: Emacs fatal error: assertion failed: !overflow Here's the backtrace, FTR: #1 0x0133f574 in emacs_abort () at w32fns.c:10832 #2 0x01159bd7 in terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:409 #3 0x01218a3e in die (msg=0x173efad <STRING_BYTES_MAX+1977> "!overflow", file=0x173e5aa <DEFAULT_REHASH_SIZE+286> "alloc.c", line=4646) at alloc.c:7362 #4 0x012124da in mark_maybe_object (obj=XIL(0xc0000000058ab680)) at alloc.c:4646 #5 0x012129e4 in mark_memory (start=0x82d818, end=0x82feac) at alloc.c:4864 #6 0x01212a0c in mark_stack (bottom=0x82feac "", end=0x82d818 "H╪ג") at alloc.c:5047 #7 0x0132015b in mark_one_thread (thread=0x1703000 <main_thread>) at thread.c:630 #8 0x01320290 in mark_threads_callback (ignore=0x0) at thread.c:661 #9 0x01212a36 in flush_stack_call_func1 ( func=0x1320212 <mark_threads_callback>, arg=0x0) at alloc.c:5088 #10 0x0131f39a in flush_stack_call_func ( func=0x1320212 <mark_threads_callback>, arg=0x0) at lisp.h:3837 #11 0x013202c0 in mark_threads () at thread.c:668 #12 0x0121555c in garbage_collect () at alloc.c:6077 #13 0x01215b05 in Fgarbage_collect () at alloc.c:6193 #14 0x01258cdf in eval_sub (form=XIL(0xc0000000058ac280)) at eval.c:2271 #15 0x012517f0 in Fprogn (body=XIL(0)) at eval.c:462 #16 0x0125c82b in funcall_lambda (fun=XIL(0xc0000000058ac2d0), nargs=1, arg_vector=0x82e010) at eval.c:3065 #17 0x0125b3de in Ffuncall (nargs=2, args=0x82e008) at eval.c:2809 #18 0x01259c69 in funcall_nil (nargs=2, args=0x82e008) at eval.c:2436 #19 0x0125a2d8 in run_hook_with_args (nargs=2, args=0x82e008, funcall=0x1259c51 <funcall_nil>) at eval.c:2613 #20 0x01259ce1 in Frun_hook_with_args (nargs=2, args=0x82e008) at eval.c:2478 #21 0x0125b678 in funcall_subr (subr=0x170bb60 <Srun_hook_with_args>, numargs=2, args=0x82e008) at eval.c:2848 #22 0x0125b1e6 in Ffuncall (nargs=3, args=0x82e000) at eval.c:2795 #23 0x012c50a5 in exec_byte_code (bytestr=XIL(0x8000000005a35ad8), vector=XIL(0xa000000005888560), maxdepth=make_fixnum(12), args_template=make_fixnum(257), nargs=1, args=0x82e6a0) at bytecode.c:635 #24 0x0125bd15 in fetch_and_exec_byte_code (fun=XIL(0xa000000005888670), syms_left=make_fixnum(257), nargs=1, args=0x82e698) at eval.c:2917 #25 0x0125c292 in funcall_lambda (fun=XIL(0xa000000005888670), nargs=1, arg_vector=0x82e698) at eval.c:2998 #26 0x0125b240 in Ffuncall (nargs=2, args=0x82e690) at eval.c:2797 #27 0x0125a512 in call1 (fn=XIL(0x5040), arg1=XIL(0x8000000005a38c08)) at eval.c:2655 #28 0x012a50bc in Fload (file=XIL(0x8000000005a38ba8), noerror=XIL(0), nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1480 #29 0x01258f1c in eval_sub (form=XIL(0xc0000000058ac310)) at eval.c:2288 #30 0x012a7c23 in readevalloop (readcharfun=XIL(0x6d20), infile0=0x82f5fc, sourcename=XIL(0x800000000599cc10), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2096 #31 0x012a4f1c in Fload (file=XIL(0x800000000599cb50), noerror=XIL(0), nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1465 #32 0x01258f1c in eval_sub (form=XIL(0xc000000005895120)) at eval.c:2288 #33 0x012581b0 in Feval (form=XIL(0xc000000005895120), lexical=XIL(0)) at eval.c:2103 #34 0x0116160f in top_level_2 () at keyboard.c:1100 #35 0x012557e0 in internal_condition_case (bfun=0x11615dc <top_level_2>, handlers=XIL(0x90), hfun=0x1160d8d <cmd_error>) at eval.c:1356 #36 0x01161689 in top_level_1 (ignore=XIL(0)) at keyboard.c:1108 #37 0x012549ed in internal_catch (tag=XIL(0xe070), func=0x1161615 <top_level_1>, arg=XIL(0)) at eval.c:1117 #38 0x011614e1 in command_loop () at keyboard.c:1069 #39 0x0116081d in recursive_edit_1 () at keyboard.c:714 #40 0x01160a8b in Frecursive_edit () at keyboard.c:786 #41 0x0115c2a0 in main (argc=5, argv=0xa44250) at emacs.c:2043 Lisp Backtrace: "Automatic GC" (0x0) "garbage-collect" (0x82daf8) 0x58ac2d0 Lisp type 6 "run-hook-with-args" (0x82e008) "do-after-load-evaluation" (0x82e698) "load" (0x82edf8) "load" (0x82f758) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 19:26 ` Eli Zaretskii @ 2020-08-01 19:40 ` Philipp Stephani 2020-08-02 16:08 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Philipp Stephani @ 2020-08-01 19:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, raman, Emacs developers Am Sa., 1. Aug. 2020 um 21:26 Uhr schrieb Eli Zaretskii <eliz@gnu.org>: > > > Date: Sat, 01 Aug 2020 22:21:24 +0300 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: alan@idiocy.org, emacs-devel@gnu.org, raman@google.com > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Sat, 1 Aug 2020 21:17:05 +0200 > > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, > > > Emacs developers <emacs-devel@gnu.org> > > > > > > I've now used INT_SUBTRACT_WRAPV, which should guarantee that the > > > offset is defined and fits within an intptr_t. > > > > Thanks, the warning is gone now. Though I still don't like the code > > there, it feels wrong even if it isn't. > > I spoke too soon: it compiles, but that hits assertion violation while > loading: Yeah, that's what I feared. I've now made the assertion conditional. It might be cleaner to rewrite that function to explicitly check for all known tag types: void *po; switch (type_tag) { case Lisp_Symbol: po = XSYMBOL (obj); break; ... } That way, the pointer arithmetic would be centralized in XUNTAG and XSYMBOL. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 19:40 ` Philipp Stephani @ 2020-08-02 16:08 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2020-08-02 16:08 UTC (permalink / raw) To: Philipp Stephani; +Cc: alan, raman, emacs-devel > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 1 Aug 2020 21:40:02 +0200 > Cc: Alan Third <alan@idiocy.org>, Emacs developers <emacs-devel@gnu.org>, raman <raman@google.com> > > Yeah, that's what I feared. I've now made the assertion conditional. The assertion is gone, thanks. > It might be cleaner to rewrite that function to explicitly check for > all known tag types: Something like that. Anything, really, because when I see the likes of # define lisp_h_XLP(o) ((void *) (uintptr_t) (o)) and know that 'o' can be a 64-bit integer whereas pointers are 32-bit wide, I get shivers. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 17:32 ` Philipp Stephani 2020-08-01 17:51 ` Eli Zaretskii @ 2020-08-01 18:09 ` T.V Raman 2020-08-01 18:13 ` Alan Third 2 siblings, 0 replies; 23+ messages in thread From: T.V Raman @ 2020-08-01 18:09 UTC (permalink / raw) To: Philipp Stephani; +Cc: Alan Third, Eli Zaretskii, Emacs developers Philipp Stephani <p.stephani2@gmail.com> writes: builds correctly > Am Sa., 1. Aug. 2020 um 17:38 Uhr schrieb Alan Third <alan@idiocy.org>: >> >> On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote: >> > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your >> > src/config.h? If so, it sounds like the configure-time test for this >> > functionality is incomplete. >> >> I'm getting a similar error: >> >> CCLD temacs >> Undefined symbols for architecture x86_64: >> "___lsan_ignore_object", referenced from: >> _enlarge_buffer_text in buffer.o >> _Fmake_variable_buffer_local in data.o >> _Fmake_local_variable in data.o >> _Fmodule_load in emacs-module.o >> _initialize_environment in emacs-module.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see invocation) >> make[1]: *** [temacs] Error 1 >> make: *** [src] Error 2 >> >> # grep SANITIZER src/config.h >> #define HAVE_SANITIZER_LSAN_INTERFACE_H 1 > > I've pushed commit 06310cf912 which should hopefully fix this, could > you please try again? -- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 17:32 ` Philipp Stephani 2020-08-01 17:51 ` Eli Zaretskii 2020-08-01 18:09 ` T.V Raman @ 2020-08-01 18:13 ` Alan Third 2 siblings, 0 replies; 23+ messages in thread From: Alan Third @ 2020-08-01 18:13 UTC (permalink / raw) To: Philipp Stephani; +Cc: Eli Zaretskii, Emacs developers, raman On Sat, Aug 01, 2020 at 07:32:40PM +0200, Philipp Stephani wrote: > Am Sa., 1. Aug. 2020 um 17:38 Uhr schrieb Alan Third <alan@idiocy.org>: > > > > On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote: > > > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your > > > src/config.h? If so, it sounds like the configure-time test for this > > > functionality is incomplete. > > > > I'm getting a similar error: > > > > CCLD temacs > > Undefined symbols for architecture x86_64: > > "___lsan_ignore_object", referenced from: > > _enlarge_buffer_text in buffer.o > > _Fmake_variable_buffer_local in data.o > > _Fmake_local_variable in data.o > > _Fmodule_load in emacs-module.o > > _initialize_environment in emacs-module.o > > ld: symbol(s) not found for architecture x86_64 > > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > make[1]: *** [temacs] Error 1 > > make: *** [src] Error 2 > > > > # grep SANITIZER src/config.h > > #define HAVE_SANITIZER_LSAN_INTERFACE_H 1 > > I've pushed commit 06310cf912 which should hopefully fix this, could > you please try again? Builds now. Thanks. -- Alan Third ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: san_ignore_object not found at link time 2020-08-01 14:45 ` Eli Zaretskii 2020-08-01 15:02 ` Philipp Stephani 2020-08-01 15:38 ` Alan Third @ 2020-08-01 16:43 ` T.V Raman 2 siblings, 0 replies; 23+ messages in thread From: T.V Raman @ 2020-08-01 16:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Philipp Stephani, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: yes, it's defined in config.h >> Date: Sat, 01 Aug 2020 17:37:56 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: emacs-devel@gnu.org >> >> > From: "T.V Raman" <raman@google.com> >> > Date: Sat, 1 Aug 2020 07:10:14 -0700 (PDT) >> > >> > Building emacs from head breaks like so: >> > >> > /usr/bin/ld: emacs-module.o: in function `Fmodule_load': >> > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object' >> > collect2: error: ld returned 1 exit status >> > make: *** [Makefile:650: temacs] Error 1 >> >> Please try again, I think I fixed that a few minutes ago. > > Actually, I fixed a different problem, sorry. > > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your > src/config.h? If so, it sounds like the configure-time test for this > functionality is incomplete. -- ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-08-02 16:08 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-08-01 14:10 san_ignore_object not found at link time T.V Raman 2020-08-01 14:37 ` Eli Zaretskii 2020-08-01 14:45 ` T.V Raman 2020-08-01 14:45 ` Eli Zaretskii 2020-08-01 15:02 ` Philipp Stephani 2020-08-01 15:38 ` Alan Third 2020-08-01 17:32 ` Philipp Stephani 2020-08-01 17:51 ` Eli Zaretskii 2020-08-01 18:02 ` Eli Zaretskii 2020-08-01 18:33 ` Philipp Stephani 2020-08-01 18:52 ` Andreas Schwab 2020-08-01 18:29 ` Philipp Stephani 2020-08-01 18:32 ` Eli Zaretskii 2020-08-01 18:35 ` Philipp Stephani 2020-08-01 19:17 ` Philipp Stephani 2020-08-01 19:21 ` Philipp Stephani 2020-08-01 19:21 ` Eli Zaretskii 2020-08-01 19:26 ` Eli Zaretskii 2020-08-01 19:40 ` Philipp Stephani 2020-08-02 16:08 ` Eli Zaretskii 2020-08-01 18:09 ` T.V Raman 2020-08-01 18:13 ` Alan Third 2020-08-01 16:43 ` T.V Raman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.