public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers
@ 2021-12-01 3:05 ashimida at linux dot alibaba.com
2021-12-01 6:56 ` [Bug libgcc/103510] " ashimida at linux dot alibaba.com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: ashimida at linux dot alibaba.com @ 2021-12-01 3:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
Bug ID: 103510
Summary: _Unwind_GetGR crashed for uninitialized registers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ashimida at linux dot alibaba.com
Target Milestone: ---
When use _Unwind_Backtrace with a callback funciton for backtrace,
if the reg corresponding to i is not initialized when calling
_Unwind_GetGR(context, i) in the callback, it will cause a crash
due to 0 address dereference.
Although the register status can be predicted by calling
_Unwind_GetGRPtr or other methods, these functions are not within
the LSB standard.
Clang works fine for this. Is there any way for me to write a common
backtrace function that uses _Unwind_Backtrace, or is it reasonable
to initialize all context->reg[x] with the values of all hardware
registers at the beginning of unwind?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
2021-12-01 3:05 [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers ashimida at linux dot alibaba.com
@ 2021-12-01 6:56 ` ashimida at linux dot alibaba.com
2021-12-02 3:46 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: ashimida at linux dot alibaba.com @ 2021-12-01 6:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
--- Comment #1 from ashimida <ashimida at linux dot alibaba.com> ---
For example, such a c code works find in clang with libunwind,
and will cause a crash in gcc with libgcc in aarch64.
#include <stdio.h>
#include <stdlib.h>
#include <unwind.h>
_Unwind_Reason_Code callback(struct _Unwind_Context *context, void *args)
{
printf("Unwind Frame X0:%016lx\n", _Unwind_GetGR(context, 0));
return _URC_NO_REASON;
}
int main(void)
{
_Unwind_Backtrace(callback, NULL);
return 0;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
2021-12-01 3:05 [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers ashimida at linux dot alibaba.com
2021-12-01 6:56 ` [Bug libgcc/103510] " ashimida at linux dot alibaba.com
@ 2021-12-02 3:46 ` pinskia at gcc dot gnu.org
2021-12-02 4:03 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-02 3:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Funny there is a comment in the libgcc sources:
/* This will segfault if the register hasn't been saved. */
Which has been there since day 1 of IA-64 ABI exception handling back in
g:52a11cbfcf0cfb32628b6953588b6af4037ac0b6
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
2021-12-01 3:05 [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers ashimida at linux dot alibaba.com
2021-12-01 6:56 ` [Bug libgcc/103510] " ashimida at linux dot alibaba.com
2021-12-02 3:46 ` pinskia at gcc dot gnu.org
@ 2021-12-02 4:03 ` pinskia at gcc dot gnu.org
2021-12-02 14:48 ` ashimida at linux dot alibaba.com
2021-12-10 2:26 ` ashimida at linux dot alibaba.com
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-02 4:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The only registers which are saved are the callee saved register IIRC. So you
need to know the ABI.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
2021-12-01 3:05 [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers ashimida at linux dot alibaba.com
` (2 preceding siblings ...)
2021-12-02 4:03 ` pinskia at gcc dot gnu.org
@ 2021-12-02 14:48 ` ashimida at linux dot alibaba.com
2021-12-10 2:26 ` ashimida at linux dot alibaba.com
4 siblings, 0 replies; 6+ messages in thread
From: ashimida at linux dot alibaba.com @ 2021-12-02 14:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
--- Comment #4 from ashimida <ashimida at linux dot alibaba.com> ---
(In reply to Andrew Pinski from comment #3)
> The only registers which are saved are the callee saved register IIRC. So
> you need to know the ABI.
Thanks Andrew,
I saw the following description in the IA-64 C++ ABI [1]:
"All registers specified as callee-saved by the base ABI are restored,
as well as scratch registers GR15, GR16, GR17 and GR18 (see below).
Except for those exceptions, scratch (or caller-saved) registers are
not preserved, and their contents are undefined on transfer."
My understanding is that the ABI states that 4 scratch registers and
callee-saved need to be 'restored' before transferring conrtrol to
landing pad. But AFAIK, the ABI does not specify whether unwind should
'initialize' all registers to context->reg[] at the beginning (please
correct me if it's wrong).
One more thing is that _Unwind_Backtrace seems to be defined in the LSB
standard (I did't find its definition in the IA-64 C++ ABI).
PS:
The reason why I am struggling with this detail is because a similar case
happened when I try to support the unwind for SCS[2] on aarch64, I found
that uw_init_context_1 did not save all the registers, which would cause
a crash when a ".cfi_escape 0x16, 0x12, 0x02, 0x82, 0x78" directive
(means x18 -= 8) was executed, which would not happen in clang.
Initializing non-call-saved registers in uw_init_context_1 can solve
those issue, but i'm not sure enough if this breaks the ABI rules.
[1] https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585199.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
2021-12-01 3:05 [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers ashimida at linux dot alibaba.com
` (3 preceding siblings ...)
2021-12-02 14:48 ` ashimida at linux dot alibaba.com
@ 2021-12-10 2:26 ` ashimida at linux dot alibaba.com
4 siblings, 0 replies; 6+ messages in thread
From: ashimida at linux dot alibaba.com @ 2021-12-10 2:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
--- Comment #5 from ashimida <ashimida at linux dot alibaba.com> ---
(In reply to Andrew Pinski from comment #3)
> The only registers which are saved are the callee saved register IIRC. So
> you need to know the ABI.
Hi Andrew,
Is it reasonable to save all registers (include callee-used registers) at
the entry of functions such as _Unwind_Backtrace/_Unwind_RaiseException
(through a change in uw_init_context)?
Then all registers will have initial values and will not affect the
execution of .cfi directives. I think this would not violate the
IA-64 C++ ABI.
I'd like to add a patch for this if it sounds reasonable.
Thanks,
Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-10 2:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-01 3:05 [Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers ashimida at linux dot alibaba.com
2021-12-01 6:56 ` [Bug libgcc/103510] " ashimida at linux dot alibaba.com
2021-12-02 3:46 ` pinskia at gcc dot gnu.org
2021-12-02 4:03 ` pinskia at gcc dot gnu.org
2021-12-02 14:48 ` ashimida at linux dot alibaba.com
2021-12-10 2:26 ` ashimida at linux dot alibaba.com
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).