https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Thomas Neumann changed:
What|Removed |Added
Attachment #57679|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Thomas Neumann changed:
What|Removed |Added
Attachment #57675|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Thomas Neumann changed:
What|Removed |Added
Attachment #57669|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #11 from Thomas Neumann ---
Created attachment 57669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57669&action=edit
patch to handle overlapping ranges
Does this patch fix the problem for you? I think it should, but I would r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #9 from Thomas Neumann ---
I will check how we can handle such a situation. But how did this happen to
begin with? Is this regular code or did you do anything special? I am puzzled
how the unwinding table can be placed like that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #7 from Thomas Neumann ---
Is it correct that in your case range[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #4 from Thomas Neumann ---
It looks like the code does not find an unwind frame when de-registering an
exception handler. Are you sure that you do not de-register a dynamic frame
twice?
Otherwise I would need a way to reproduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #8 from Thomas Neumann ---
Created attachment 55715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55715&action=edit
patch to use the correct base pointer
The attached patch fixes the test case by using the correct base pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #7 from Thomas Neumann ---
Thanks for the pointer, I could reproduce the problem in a VM now.
That shared library uses an usual table encoding that has to reference the
original base pointer within get_pc_range. But when deregisteri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #5 from Thomas Neumann ---
The assert itself is old, it was just updated due to code changes. And
asserting there makes sense, if we keep an old frame around we might see a
crash later during unwinding if the unwinder tries to access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #4 from Thomas Neumann ---
I am not sure what caused that, but in GCC 13 the unwinding logic now looks
into the table when registering the frame, while previously the table was only
inspected on the first exception. Which means we mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #1 from Thomas Neumann ---
The assert says that the code tries to de-register a frame that it did not
register before or that was deregistered before. If you see that failing you
might want to add some print statements to
__register_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
--- Comment #6 from Thomas Neumann ---
> GCC 13.2 is being released, retargeting bugs to GCC 13.3.
the bug should be closed as fixed, the bug fix is already in the 13.2 branch.
(I do not have permissions to do that, though).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #19 from Thomas Neumann ---
I think we can close this bug as fixed, but I do not have permissions to do
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #26 from Thomas Neumann ---
(In reply to Florian Weimer from comment #23)
>
> u is the original read pointer as far as I can see. So it looks like it
> should look like this:
>
> diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #21 from Thomas Neumann ---
It must be something more complex. value is small here (more precisely: 1888 in
the crashes later), which is not a valid pointer address. We probably have to
add this to some base pointer? But it is not ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #19 from Thomas Neumann ---
Hm, then I don't know how we end up with the non-regular table content. The
code checks for hdr->fde_count_enc != DW_EH_PE_omit, and that is false in the
executable that you provided.
But regardless of wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #17 from Thomas Neumann ---
The bug was introduced by gcc commit e724b04. It avoids calls to
read_encoded_value_with_base for performance reasons, but unfortunately this
causes the variable eh_frame to be uninitialized if the fast pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Thomas Neumann changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #14 from Thomas Neumann ---
I cannot reproduce the problem, but admittedly I used a newer Ubuntu version. I
tried compiling it with gcc 7.5.0, linking it with gold 1.16, and using the gcc
version you specified (07c52d1eec9) for the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #12 from Thomas Neumann ---
Created attachment 55037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55037&action=edit
radix sort fix
I could reproduce the problem, the radix sort did not behave correctly when we
ran out of bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #10 from Thomas Neumann ---
(In reply to LIU Hao from comment #9)
> GDB is affected, too:
I will debug that. That is easier to build than Ada. Strange that it only
affects 32bit Windows. I will take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #8 from Thomas Neumann ---
Do you by chance an Ada-enabled WIN32 toolchain somewhere that I can use to
build gcc with? Or an script on how to do that? I have not managed to reproduce
the problem yet, unfortunately, because I could no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
--- Comment #2 from Thomas Neumann ---
I can reproduce the issue. The attached patch fixes the problem, I will send it
for reviewing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
--- Comment #1 from Thomas Neumann ---
Created attachment 54969
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54969&action=edit
fix for the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #16 from Thomas Neumann ---
I have committed a fix:
commit 6e56633daae79f514b0e71f4d9849bcd8d9ce71f
Author: Thomas Neumann
Date: Fri Dec 9 18:23:44 2022 +0100
initialize fde objects lazily
When registering an unwind fram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #15 from Thomas Neumann ---
> You cannot use 'relaxed' atomic load in is_object_initialized - as thread
> performing such load will not observe/synchronize with any modifications
> (other than atomic variable itself) performed by oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107026
--- Comment #9 from Thomas Neumann ---
Yes, commit 386ebf75f4c0342b1f823f4e4aba07abda3288d1 fixes the assert.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107026
--- Comment #6 from Thomas Neumann ---
I have a patch ready, I am waiting for approval:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602130.html
When using the atomic fast path deregistering can fail during
program shutdown if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714
--- Comment #3 from Thomas Neumann ---
Perhaps the header files could be changed to react to _REENTRANT, as that seems
to be the define that is set by gcc when requesting threading support.
The redundant checks within the shared library are less
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: tneumann at users dot sourceforge.net
Target Milestone: ---
Currently the libgcc code uses a weak symbol to recognize if the program is
linked again pthreads (in __gthread_active_p()), and switches between
31 matches
Mail list logo
