Sending this again, as the mailer daemon rejected it last time.... It looks good to me, but I can only approve the files that go into libvtv.
In (belated) response to your earlier question about debugging vtv problems, there's a fair amount of useful info for debugging in the User's Guide, off the wiki page (https://gcc.gnu.org/wiki/vtv). If you're already read that and have further questions, let me know... -- Caroline cmt...@google.com On Mon, Oct 19, 2015 at 4:39 PM, Caroline Tice <cmt...@google.com> wrote: > It looks good to me, but I can only approve the files that go into libvtv. > > In (belated) response to your earlier question about debugging vtv problems, > there's a fair amount of useful info for debugging in the User's Guide, off > the wiki page (https://gcc.gnu.org/wiki/vtv). If you're already read that > and have further questions, let me know... > > > -- Caroline > cmt...@google.com > > On Mon, Oct 19, 2015 at 1:54 AM, Ramana Radhakrishnan > <ramana....@googlemail.com> wrote: >> >> On Tue, Oct 13, 2015 at 1:53 PM, Ramana Radhakrishnan >> <ramana.radhakrish...@foss.arm.com> wrote: >> > >> > >> > >> > On 12/10/15 21:44, Jeff Law wrote: >> >> On 10/09/2015 03:17 AM, Ramana Radhakrishnan wrote: >> >>> This started as a Friday afternoon project ... >> >>> >> >>> It turned out enabling VTV for AArch64 and ARM was a matter of fixing >> >>> PR67868 which essentially comes from building libvtv with section >> >>> anchors turned on. The problem was that the flow of control from >> >>> output_object_block through to switch_section did not have the same >> >>> special casing for the vtable section that exists in >> >>> assemble_variable. >> >> That's some ugly code. You might consider factoring that code into a >> >> function and just calling it from both places. Your version doesn't seem >> >> to >> >> handle PECOFF, so I'd probably refactor from assemble_variable. >> >> >> > >> > I was a bit lazy as I couldn't immediately think of a target that would >> > want PECOFF, section anchors and VTV. That combination seems to be quite >> > rare, anyway point taken on the refactor. >> > >> > Ok if no regressions ? >> >> Ping. >> >> Ramana >> >> > >> >>> >> >>> However both these failures also occur on x86_64 - so I'm content to >> >>> declare victory on AArch64 as far as basic enablement goes. >> >> Cool. >> >> >> >>> >> >>> 1. Are the generic changes to varasm.c ok ? 2. Can we take the >> >>> AArch64 support in now, given this amount of testing ? Marcus / >> >>> Caroline ? 3. Any suggestions / helpful debug hints for VTV debugging >> >>> (other than turning VTV_DEBUG on and inspecting trace) ? >> >> I think that with refactoring they'd be good to go. No opinions on the >> >> AArch64 specific question -- call for the AArch64 maintainers. >> >> >> >> Good to see someone hacking on vtv. It's in my queue to look at as >> >> well. >> > >> > Yeah figuring out more about vtv is also in my background queue. >> > >> > regards >> > Ramana >> > >> > PR other/67868 >> > >> > * varasm.c (assemble_variable): Move special vtv handling to.. >> > (handle_vtv_comdat_sections): .. here. New function. >> > (output_object_block): Handle vtv sections. >> > >> > libvtv/Changelog >> > >> > * configure.tgt: Support aarch64 and arm. > >
