* 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 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
* 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 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 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: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: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: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 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
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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).