https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #46 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a307a26e8b392ba65edfdae15489556b7701db81
commit r14-9387-ga307a26e8b392ba65edfdae15489556b7701db81
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #45 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Lukas Grätz from comment #9)
> > Well it is not my testcase. But I added backtracing and observed that the
> > printed backtrace is unchanged with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #44 from Lukas Grätz ---
(In reply to Tom Tromey from comment #39)
> (In reply to Lukas Grätz from comment #36)
>
> > > #2 0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > > d=,
> > > e=, f= > > reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #43 from Lukas Grätz ---
(In reply to Lukas Grätz from comment #42)
> (In reply to Jakub Jelinek from comment #41)
> >
> > No. When PR78685 would be fixed by adding artificial hidden uses of
> > variables at the end of their
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #42 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #41)
> (In reply to Lukas Grätz from comment #40)
> > It seems that the reason for is ultimately -Og, not this
> > patch. See Bug 78685.
>
> No. When PR78685 would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #41 from Jakub Jelinek ---
(In reply to Lukas Grätz from comment #40)
> It seems that the reason for is ultimately -Og, not this
> patch. See Bug 78685.
No. When PR78685 would be fixed by adding artificial hidden uses of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #40 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Lukas Grätz from comment #29)
> > I belief this could and should be somehow be fixed by adding DWARF info that
> > certain callee-saved registers (=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #39 from Tom Tromey ---
(In reply to Lukas Grätz from comment #36)
> > #2 0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > d=,
> > e=, f= > reading variable: value has been optimized out>, g=48, h=49)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #38 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #37)
> Nowhere, just run and when it stops due to abort, just up several times
> until reaching the appropriate frame.
I see, this gives me:
(gdb) frame 4
#4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #37 from Jakub Jelinek ---
Nowhere, just run and when it stops due to abort, just up several times until
reaching the appropriate frame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #36 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #35)
> If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
> + .cfi_undefined 3
> + .cfi_undefined 12
> + .cfi_undefined 13
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #35 from Jakub Jelinek ---
If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
+ .cfi_undefined 3
+ .cfi_undefined 12
+ .cfi_undefined 13
+ .cfi_undefined 14
+ .cfi_undefined 15
then bt in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #34 from Jakub Jelinek ---
Best effort are the whatever@entry values, that is used if an argument is no
longer used across the function call and isn't stored in any call saved
register or stack slot.
There can be also automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #33 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #32)
> (In reply to Lukas Grätz from comment #31)
> > Even when I compile a simple program with gcc -O2 -g:
> >
> > #include
> > int main(int argc, char** argv) {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #32 from Jakub Jelinek ---
(In reply to Lukas Grätz from comment #31)
> Even when I compile a simple program with gcc -O2 -g:
>
> #include
> int main(int argc, char** argv) {
> abort();
> }
>
>
> I still get an "argc=":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #31 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Lukas Grätz from comment #29)
> > Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I
> > trusted comment #10 here, as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #30 from Jakub Jelinek ---
(In reply to Lukas Grätz from comment #29)
> Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I
> trusted comment #10 here, as it made sense.
See PR114116.
> glibc's backtrace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #29 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Lukas Grätz from comment #9)
> > Well it is not my testcase. But I added backtracing and observed that the
> > printed backtrace is unchanged with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #28 from Jakub Jelinek ---
(In reply to Lukas Grätz from comment #9)
> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():
You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #27 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Lukas Grätz from comment #25)
> > (In reply to Jakub Jelinek from comment #19)
> > > (In reply to H.J. Lu from comment #18)
> > > > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #26 from Jakub Jelinek ---
(In reply to Lukas Grätz from comment #25)
> (In reply to Jakub Jelinek from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Jakub Jelinek from comment #17)
> > > > E.g. shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #25 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Jakub Jelinek from comment #17)
> > > E.g. shouldn't it at least be disabled for -O0 and -Og and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #24 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:291f75fa1bc6a23c6184bb99c726074b13f2f18e
commit r14-8495-g291f75fa1bc6a23c6184bb99c726074b13f2f18e
Author: H.J. Lu
Date: Sat Jan 27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #23 from H.J. Lu ---
(In reply to Andrew Burgess from comment #21)
> Setting to DW_CFA_undefined is the right thing to do. DWARF says:
>
> The DW_CFA_undefined instruction takes a single unsigned LEB128 operand
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #22 from H.J. Lu ---
Created attachment 57243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57243=edit
A patch to generate .cfi_undefined for unsaved callee-saved registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #21 from Andrew Burgess ---
Setting to DW_CFA_undefined is the right thing to do. DWARF says:
The DW_CFA_undefined instruction takes a single unsigned LEB128 operand
that represents a register number. The required action is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Jakub Jelinek changed:
What|Removed |Added
CC||aburgess at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #19 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #18)
> (In reply to Jakub Jelinek from comment #17)
> > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
>
> We can disable this for -O0 and -Og.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #18 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #17)
> E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
We can disable this for -O0 and -Og.
> somehow indicate in DWARF unwind info that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #17 from Jakub Jelinek ---
E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we somehow
indicate in DWARF unwind info that the callee saved registers weren't saved and
were clobbered? Even if backtrace itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #15 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:7cc9adc62cee0aa91ce834b3dd6296ce38f1d79d
commit r14-8470-g7cc9adc62cee0aa91ce834b3dd6296ce38f1d79d
Author: H.J. Lu
Date: Tue Jan 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #14 from Lukas Grätz ---
Never mind my above comments. I just realized that attribute nothrow has no
effect in C, unless -fexceptions. So nothrow is not needed (only
-fno-exceptions). Furthermore, most noreturn functions throw in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #13 from Lukas Grätz ---
(In reply to Lukas Grätz from comment #12)
> CODE, uses loop unwinding functions
>a) restores all callee-saved registers in f3(), f2()
>b) restores %rsp and %rip from stack of f2()
I meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #12 from Lukas Grätz ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++. I fixed it by
> keeping callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #11 from Lukas Grätz ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++. I fixed it by
> keeping callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #10 from H.J. Lu ---
(In reply to Lukas Grätz from comment #9)
> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():
>
> void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #9 from Lukas Grätz ---
(In reply to H.J. Lu from comment #8)
> (In reply to Lukas Grätz from comment #7)
> > (In reply to H.J. Lu from comment #4)
> > > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #7 from Lukas Grätz ---
(In reply to H.J. Lu from comment #4)
> When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> most of C++ exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Lukas Grätz changed:
What|Removed |Added
CC||lukas.graetz@tu-darmstadt.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #4 from H.J. Lu ---
When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
most of C++ exception tests crashed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Julian Stecklina js at alien8 dot de changed:
What|Removed |Added
CC||js at alien8 dot de
--- Comment #2 from thutt at vmware dot com 2008-12-16 14:03 ---
(In reply to comment #1)
The reason why they are saved is so that you can have a good way of debugging
noreturn functions.
Can you please elaborate? How is saving these registers, which will never be
restored, going
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-15 23:26 ---
The reason why they are saved is so that you can have a good way of debugging
noreturn functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
46 matches
Mail list logo
