Help with PR97872
Hi, For the test mentioned in PR, I was trying to see if we could do specialized expansion for vcond in target when operands are -1 and 0. arm_expand_vcond gets the following operands: (reg:V8QI 113 [ _2 ]) (reg:V8QI 117) (reg:V8QI 118) (lt (reg/v:V8QI 115 [ a ]) (reg/v:V8QI 116 [ b ])) (reg/v:V8QI 115 [ a ]) (reg/v:V8QI 116 [ b ]) where r117 and r118 are set to vector constants -1 and 0 respectively. However, I am not sure if there's a way to check if the register is constant during expansion time (since we don't have df analysis yet) ? Alternatively, should we add a target hook that returns true if the result of vector comparison is set to all-ones or all-zeros, and then use this hook in gimple ISEL to effectively turn VEC_COND_EXPR into nop ? Thanks, Prathamesh
Re: Help with PR97872
On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote: > Hi, > For the test mentioned in PR, I was trying to see if we could do > specialized expansion for vcond in target when operands are -1 and 0. > arm_expand_vcond gets the following operands: > (reg:V8QI 113 [ _2 ]) > (reg:V8QI 117) > (reg:V8QI 118) > (lt (reg/v:V8QI 115 [ a ]) > (reg/v:V8QI 116 [ b ])) > (reg/v:V8QI 115 [ a ]) > (reg/v:V8QI 116 [ b ]) > > where r117 and r118 are set to vector constants -1 and 0 respectively. > However, I am not sure if there's a way to check if the register is > constant during expansion time (since we don't have df analysis yet) ? > > Alternatively, should we add a target hook that returns true if the > result of vector comparison is set to all-ones or all-zeros, and then > use this hook in gimple ISEL to effectively turn VEC_COND_EXPR into nop ? Would everything match-up for a .VEC_CMP IFN producing a non-mask vector type? ISEL could special case the a ? -1 : 0 case this way. > Thanks, > Prathamesh > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
RE: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)
Mark, Thank you very much for the help. I was so fixated on the fact that the .rela.debug* sections were there that I didn't pay attention to the e_type in the ELF header. Apparently, neither did the library that I was using to parse the DWARF data. Interestingly, I have seen other non-RedHat kernel debug images where the kernel is ET_EXEC and there are still .rela.debug* sections present in the image. Though the effect of applying those relocs has always been nil (the data in the original .debug* section is already the same as what the .rela.debug* section indicates to alter). Sincerely, Bill Messmer -Original Message- From: Mark Wielaard Sent: Monday, November 30, 2020 6:39 PM To: Bill Messmer Cc: gcc@gcc.gnu.org Subject: Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references) Hi Bill, On Mon, Nov 30, 2020 at 10:22:34PM +, Bill Messmer wrote: > I'm still a bit confused here. And the reason I ask this is because I > open this particular vmlinux image with an OSS ELF/DWARF library... > which gives me the *WRONG* names for various DWARF DIEs. > I stepped through the library... and the reason the names are wrong > is because the library applies all of the relocations in > .rela.debug_info to the sections it opens. I thought there might be a > bug in the library somewhere, so I started down looking at the DWARF > data with standard Linux tools and in hex dumps... and it seemed > incorrect to my -- admittedly limited -- understanding... > > Yes, I am using llvm-dwarfdump to textualize the DWARF data > (llvm-dwarfdump-10 --verbose vmlinux) and I would assume(?) this > applies the relocations as necessary. And I am using readelf to get > the section data (readelf -S vmlinux) and the relocation data (readelf > -r vmlinuix); however, the hex data I show is just a flat hexdump of > the image (hexdump -C vmlinux -n ... -s ...). I traced your steps and did the same on a local vmlinux copy and got the same results as you. That didn't make sense to me. Till I realized my original assumption, that the vmlinux image, like kernel modules were partially linked and so ET_REL files that still needed relocation applied, seemed wrong. The vmlinux file isn't actually ET_REL, but it is ET_EXEC (see readelf -h vmlinux). In which case other tools don't apply the relocations. And so your observation is correct. The offset to the .debug_str table is right in the .debug_info section, the relocations are meaningless. That is surprising. > Either both that library and my understanding are incorrect, there is > something wrong with that relocation data, or it flat isn't supposed > to be applied... It is the last thing, the aren't supposed to be applied because it is an ET_EXEC file (which isn't supposed to have .rela.debug sections, but apparently has). > I also tried what you suggested "eu-strip -- reloc-debug-sections vmlinux -f > stripped" and looked at the resulting output: > > "readelf -S stripped" still shows the reloc sections: > > [65] .debug_info PROGBITS 00059e50 >0c458644 0 0 1 > [66] .rela.debug_info RELA 0c4b2498 >1288ae68 0018 I 7865 8 > > And that relocation is still there via "readelf -r stripped": Which now also makes sense, because as the --help text says "only relevant for ET_REL files". So you did find a real mystery, for some reason the way the vmlinux image is created does get relocations correctly applied, but they (or at least some) are still left behind in the ELF image even though they are no longer needed (and if you do try to use/apply them, you get wrong results). We should probably find out if this happened during the upstream build or during distro packaging. Cheers, Mark
Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)
On Mon, Nov 30, 2020 at 6:41 PM Mark Wielaard wrote: > > Hi Bill, > > On Mon, Nov 30, 2020 at 10:22:34PM +, Bill Messmer wrote: > > > I'm still a bit confused here. And the reason I ask this is because > > I open this particular vmlinux image with an OSS ELF/DWARF > > library... which gives me the *WRONG* names for various DWARF DIEs. > > I stepped through the library... and the reason the names are wrong > > is because the library applies all of the relocations in > > .rela.debug_info to the sections it opens. I thought there might be > > a bug in the library somewhere, so I started down looking at the > > DWARF data with standard Linux tools and in hex dumps... and it > > seemed incorrect to my -- admittedly limited -- understanding... > > > > Yes, I am using llvm-dwarfdump to textualize the DWARF data > > (llvm-dwarfdump-10 --verbose vmlinux) and I would assume(?) this > > applies the relocations as necessary. And I am using readelf to get > > the section data (readelf -S vmlinux) and the relocation data > > (readelf -r vmlinuix); however, the hex data I show is just a flat > > hexdump of the image (hexdump -C vmlinux -n ... -s ...). > > I traced your steps and did the same on a local vmlinux copy and got > the same results as you. That didn't make sense to me. Till I realized > my original assumption, that the vmlinux image, like kernel modules > were partially linked and so ET_REL files that still needed relocation > applied, seemed wrong. The vmlinux file isn't actually ET_REL, but it > is ET_EXEC (see readelf -h vmlinux). In which case other tools don't > apply the relocations. And so your observation is correct. The offset > to the .debug_str table is right in the .debug_info section, the > relocations are meaningless. That is surprising. > > > Either both that library and my understanding are incorrect, there > > is something wrong with that relocation data, or it flat isn't > > supposed to be applied... > > It is the last thing, the aren't supposed to be applied because it is > an ET_EXEC file (which isn't supposed to have .rela.debug sections, > but apparently has). > > > I also tried what you suggested "eu-strip -- reloc-debug-sections vmlinux > > -f stripped" and looked at the resulting output: > > > > "readelf -S stripped" still shows the reloc sections: > > > > [65] .debug_info PROGBITS 00059e50 > >0c458644 0 0 1 > > [66] .rela.debug_info RELA 0c4b2498 > >1288ae68 0018 I 7865 8 > > > > And that relocation is still there via "readelf -r stripped": > > Which now also makes sense, because as the --help text says "only > relevant for ET_REL files". > > So you did find a real mystery, for some reason the way the vmlinux > image is created does get relocations correctly applied, but they (or > at least some) are still left behind in the ELF image even though they > are no longer needed (and if you do try to use/apply them, you get > wrong results). We should probably find out if this happened during > the upstream build or during distro packaging. Check if CONFIG_X86_NEED_RELOCS is enabled for your kernel. -- H.J.
Re: DWARF64 gcc/clang flag discussion
On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich wrote: > > > -- > *From:* David Blaikie > *Sent:* Monday, November 30, 2020 12:09 PM > *To:* Alexander Yermolovich > *Cc:* Richard Biener ; Jakub Jelinek < > ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org < > gcc@gcc.gnu.org>; ikud...@accesssoftek.com ; > mask...@google.com > *Subject:* Re: DWARF64 gcc/clang flag discussion > > On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich > wrote: > > Thank you David for driving the conversation, sorry I was on vacation. > > > All good - really appreciate everyone chipping in whenever/however they > can! > > > > I guess discussion is from perspective of having both flags > gdwarf32/gdwarf64. In which case it's a valid question on whether they > should imply -g like -gdwarf-#. > But can this be viewed as only a -gdwarf64 flag, that is a qualifier to > other debug flags that enable debug information? DWARF spec says that 32bit > should be a default, and 64bit should be used rarely (paraphrasing). So > when user enabled debug information the default expectation is that it will > be 32bit. There is no real need for a flag to say "I want debug > information, and I want it 32bit". > > > I'm not quite with you here, I think. I believe it's important to be able > to opt into and out of things at any point on the command line - because of > how complex build systems build up command lines. You might have a > -gdwarf64 set as a project default, but for some reason want to opt into > -gdwarf32 in other parts (perhaps you're building the debug info for your > interface library you intend to ship to clients who might only have DWARF32 > support, but your library is big and needs DWARF64 for the rest). A general > architectural principle of most command line arguments to the compiler is > that they can be opted into/out of fairly symmetrically (hence all the > -*no-* variant flags). > > [Alex] Ah I see, good point. > > > On the other hand, 64bit DWARF format must be enabled. So from users > perspective it's "I want debug information enabled for particular DWARF > version and level, oh and I want it to be 64bit". > > > But there's also the possibility of wanting to turn on DWARF64 for any > debug info in your build, but not necessarily wanting to turn on debug info > while doing so. Eg: you have a big build system, with a variety of users > and flags all over the place - maybe users opting in to -g2 on some files > and -g1 on others, and/or under different build modes. And the project as a > whole is reaching the DWARF64 tipping point and you'd like to say "if we're > generating DWARF, make it DWARF64". We've recently encountered this sort of > situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we > had this situation where there's a big code base/build system with many > users, many uses of different -gN-type flags and it'd be impractical to go > and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we > added -fdebug-default-version=N (I might be misremembering the spelling) to > Clang to support this use case of "If we're generating DWARF, make it > DWARFv5") > > [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable > debug generation, but if it is enabled it will be 64bit. A "qualifier" of > sorts. > OK. My concern there, though I think it's the preferable semantics for the -gdwarf64 flag when considered in isolation, is now -gdwarf64 and -gdwarf-5 would have some fairly subtly different semantics (the latter enables debug info and the former does not) in contrast to how close their spelling is. (in addition to their general similarly maybe being a source of confusion - even if the numbers aren't close to each other) > > > This also helps to avoid the scenario if user explicitly specifies debug > level. The gcc documentation says > "If you use multiple -g options, with or without level numbers, the last > such option is the one that is effective." > With complex, like buck, build systems with various config files, and hard > coded overrides that's just asking to end up with debug level that might > not be what user expects. > > > Not quite sure I'm following here - if -gdwarf64 does enable -g by default > it might be quite confusing in such a big complicated build system - where > a user actually wanted -gmlt or -g0 or some certain library or file, but it > got overriden by -gdwarf64. (or the inverse - does -gdwarf64 -g mean > DWARF32 again because that's the default? That's probably not what people > want most of the time (but sometimes they might want to opt back into > DWARF32 later in the command line) > > [Alex] Primarily from the debug level perspective. If user specifies -g0 > or -gmlt, and -gdwarf64 (assuming it enables -g), then depending on the > order in command line where build system has put things user might end up > with level of debug information they wanted, or with default -g. > Ah, you mean in the case
