On Sun May 14, 2023 at 8:59 PM CEST, Thomas Neumann wrote:
> Dear Sören,
>
> > we ran into a regression introduced by these changes. The regression
> > manifests itself in a failing assertion in __deregister_frame_info_bases.
> > The assertion failure was observed while using Chromium's `flatc` build
> > system tool. The failing assertion is:
> > 
> > 	unwind-dw2-fde.c:281	gcc_assert (in_shutdown || ob);
> > [snip]
> > However, I believe there is one more edge case that isn't being account
> > for presently: If the inserted entry has a size of 0 (i.e. if range[1] -
> > range[0] == 0) then the btree_insert call in __register_frame_info_bases
> > will not insert anything. This is not accounted for in
>  > [snip]
> > 
> > Would be cool if this could be fixed on the GCC trunk.
>
> thanks for the details analysis and the patch, it looks obviously 
> correct for me. I can apply it to trunk, but we need approval from a gcc 
> maintainer first.
>
> But independent of your patch, do you have the test case available in 
> some easily accessible form, for example a docker image or an automated 
> build script? I ask because something odd is happening here, somebody 
> registered a non-empty EH that does not contain a single unwind range. I 
> am puzzled why anybody would do that, I would like to double check that 
> this is indeed the intended behavior and not a bug somewhere else. Or if 
> you have the test case at hand, it would be great if you could do a 
> quick step through get_pc_range for the affected frame to double-check 
> that the table is indeed empty and we don't miss an entry for some 
> strange reason.

sadly, the only instance of this breakage that i found is extremely contrived,
and involves the chromium codebase, and the flatc build in it..

even building the flatbuffers repo externally using cmake at the same revision
didn't reproduce it.

that said, i have attached a dockerfile that shows you what /does/ fail, under
the specific conditions. but there is no unpatched libgcc_s, so you'll have
to do that part yourself, and build a libgcc_s.so.1 without the patch in this
thread.

>
> Best
>
> Thomas