https://sourceware.org/bugzilla/show_bug.cgi?id=31763
--- Comment #3 from Adam Jackson <ajax at redhat dot com> --- -N works, not sure how I'd missed it in the docs, thank you. I'm not sure if there's a good way to cache the likely-negative-ness of the symbol lookup here. >From your example: > Relocation section [12] '.relr.dyn' at offset 0x4bc88 contains 750 entries: > +0x000000000044bcd0 <__frame_dummy_init_array_entry> * > +0x000000000044bcd8 <__do_global_dtors_aux_fini_array_entry> > +0x000000000044bce0 <__dso_handle> > +0x000000000044bd10 <ossl_ed448_asn1_meth+0x10> > +0x000000000044bd18 <ossl_ed448_asn1_meth+0x18> > +0x000000000044bd20 <ossl_ed448_asn1_meth+0x20> When you process 0x44bd10 you could look ahead to see that the next two have the same increment (of 0x8, though, why be picky), and probably they, and any more beyond with the same increment, would refer to offsets within a single symbol. I don't know if there's a good way to express that as a heuristic here though. -- You are receiving this mail because: You are on the CC list for the bug.
