similar to: [RFC] Updating googletest to non-release tagged version

Doesn't sound like there's opposition - can't say whether or not it's wort hit, but if you're willing to give it a go/send a patch, probably can't hurt. Might be a bit of work to get all the corners right - I think there are a few local patches to the gtest in llvm, unfortunately, that you'd have to port over, etc. On Thu, Mar 22, 2018 at 3:59 AM James Henderson <

Thanks for the comments all. I've thought about it and I agree that I can probably reduce the number of test cases, so that it is not combinatorial, in my use case. I guess the broader question still is there as to whether a) people would be opposed to updating to a non-official-release version of googletest, and b) whether it would be worthwhile doing so. As I noted previously, there is at

Yes, I imagine there will be some interesting issues. I'm away for a couple of weeks around Easter, so it will likely be a few weeks before I or anybody in my team get a chance to look at this further, but we'll certainly keep people updated on here with how it goes (or via reviews). James On 22 March 2018 at 15:03, David Blaikie <dblaikie at gmail.com> wrote: > Doesn't

On Thu, Mar 15, 2018 at 11:10 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > FWIW, I have no concerns about updating to a modern googletest. More modern the better IMO if someone is willing to do the work to make sure it works on all our platforms, etc. However: > Could you provide an example here of the

On 19 March 2018 at 19:56, Chandler Carruth <chandlerc at gmail.com> wrote: > On Thu, Mar 15, 2018 at 11:10 AM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> +Chandler who might have some thoughts on this. >> > > FWIW, I have no concerns about updating to a modern googletest. More > modern the better IMO if someone is willing to do

On Thu, Mar 15, 2018 at 9:09 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > > Could you provide an example here of the motivation for the feature you're > missing? Might help motivate the discussion (and/or we'll end up nitpicking > how it could be done differently without that feature... - which

Thanks. The motivating example can be seen in this review: https://reviews.llvm.org/D44382. In that review, I am unit testing .debug_line parsing, specifically, the behaviour when the parser is fed a malformed section. Most of the code under test goes through some slight variations in the code path, depending on a) the DWARF version (interesting cases are 3, 4 and 5), and b) whether the DWARF is

On Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: >> >> +James for context too (always good to include the folks from the >> original threads for continuity) >> >> Yeah, my general attitude there was just twofold, one that

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer

+James for context too (always good to include the folks from the original threads for continuity) Yeah, my general attitude there was just twofold, one that the discussion had strayed fairly far from the review (so interested parties might not see it, both because it's a targeted review thread on the noisy llvm-commits, and because fo the title not having much connection to the discussion)

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all

On Fri, Nov 13, 2020 at 11:29 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 11:24 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > > > > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: >

This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a mix of CU that are DWARF32/64. This is supported by DWARF format. With this

In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to join the group before making a post) Cary Coutant raised yet another idea: whether we can use ".debug64" as the section prefix. I like the idea because of: * It is immediately obvious whether DWARF64 is used and whether DWARF32 is used along with DWARF64. * In a relocatable link mixing DWARF32 and DWARF64 sections,

> Thinking about it, I wouldn't expect an LTO generated object itself to have a mixture of DWARF32/64, although I guess the 32/64 bit state could be encoded in the IR (I am not familiar enough with it to know if it actually is or not). It might be necessary to find ways to configure LTO to generate DWARF64, possibly via a link-time option. I don’t think we need to encode dwarf32/64 in IR

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

I got replies from Nick Clifton and Michael Matz: https://sourceware.org/pipermail/binutils/2020-November/114116.html (and its reply). I have mentioned (a) the difficulty of the detecting-DWARF64-by-first-relocation approach and (b) the section type approach in my reply there https://sourceware.org/pipermail/binutils/2020-November/114125.html (a) My prototype has made me feel uneasy with this

On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > I got replies from Nick Clifton and Michael Matz: > > https://sourceware.org/pipermail/binutils/2020-November/114116.html > > (and its reply). > > I have mentioned (a) the difficulty

On 2020-11-12, Alexander Yermolovich wrote: >Thanks for feedback. > >I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. > >"Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects

Looks like there is an agreement that this path, modifying lld to order sections using relocations, should be explored. If Igor doesn't object, since he was primary one driving DWARF64 so far, I would like to give it a shot at implementing and collecting some performance numbers. 🙂 Alex ________________________________ From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: