search for: debug_

...uld name the >command line option, but something that makes it unnecessary to actually >know the values you want to put in would make it easier. >-debug-comdat-relocation-filler=compat, bfd, <something> (yes, that's not >great, but it's at least a start :) > >-eric .debug_* => 0 looks good to me and I'd like to make the change because some users in this thread expressed preference, while some are bystanders, and I don't want to be the only one on the side opposite to the side of users expressing preferece. An argument I have in mind but haven't raised...

..."request for changes" blocked the change and I am not inclined to agree we would otherwise be at an impasse without the "request for changes". I would likely get an "Accept Revision" or a just textual "LGTM", even if there is a conditional request that ".debug_* should use 0 as well, like GNU ld". On Wed, Aug 5, 2020 at 11:27 AM Hans Wennborg <hans at chromium.org> wrote: > > +the people who fell off the cc list for some reason > > On Wed, Aug 5, 2020 at 8:24 PM Hans Wennborg <hans at chromium.org> wrote: > > > >...

...it unnecessary to actually >> >know the values you want to put in would make it easier. >> >-debug-comdat-relocation-filler=compat, bfd, <something> (yes, that's not >> >great, but it's at least a start :) >> > >> >-eric >> >> .debug_* => 0 looks good to me and I'd like to make the change because some >> users in this thread expressed preference, while some are bystanders, and I don't want >> to be the only one on the side opposite to the side of users expressing preferece. >> >> An argument I...

...yone. Thanks! -eric On Wed, Aug 5, 2020 at 12:13 PM Hans Wennborg <hans at chromium.org> wrote: > My apologies, I didn't realize D84825 now restores the original > behavior. The review thread is a bit hard to follow :-) > > From the change description it still sounds like .debug_ranges & > .debug_loc tombstones are changing to -2 though? Or is that what we > had before? > > To be clear, I'm not familiar with the technical details here, I'm > just keen that we end up in a known-good state. > > Also the patch is marked "release/11.x only&...

On 2020-11-17, Igor Kudrin wrote: > >On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>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 input sections are SHT_DWA...

...13 PM Hans Wennborg <hans at chromium.org> wrote: > >> > >> My apologies, I didn't realize D84825 now restores the original > >> behavior. The review thread is a bit hard to follow :-) > >> > >> From the change description it still sounds like .debug_ranges & > >> .debug_loc tombstones are changing to -2 though? Or is that what we > >> had before? > > https://reviews.llvm.org/D84825 restored the behavior. I mean, with > respect, I do not know why it was marked as "request for changes". > Otherwise, it...

...>> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical > >> > base > >> > > > >> address for shared libraries, I’d think using it has the potential > >> > to > >> > > > >> mislead various consumers.) For .debug_ranges we use -2, because > >> > both > >> > > > a > >> > > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > >> > > > >> > >> > > > > > >> > > > >Any harm...

...; >of lld with regards to resolving relocations from debug sections to dead >> >code (either comdat deduplicated, or gc-sections use). >> > >> >A very quick summary of the situation: >> > >> >Original Behavior: >> > >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 >> > elsewhere >> > - gold/lld: 0+addend everywhere >> > >> >Limitations/bugs: >> > >> > - bfd/gold/lld >> > - doesn't support 0 as a valid executable address without ambiguities >...

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jul 2...

...t; > that’s a > > > > >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical > > base > > > > >> address for shared libraries, I’d think using it has the potential > > to > > > > >> mislead various consumers.) For .debug_ranges we use -2, because > > both > > > > a > > > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > > > > >> > > > > > > > > > >Any harm in using -2 everywhere, for consistency? > > &gt...

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 input sections are SHT_DWARF64, the output section type probably...

...ress than 0x0 or 0x1. (0x0 is a typical > >> >> > base > >> >> > > > >> address for shared libraries, I’d think using it has the potential > >> >> > to > >> >> > > > >> mislead various consumers.) For .debug_ranges we use -2, because > >> >> > both > >> >> > > > a > >> >> > > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > >> >> > > > >> > >> >> > > > &g...

...rences from >> debug info to stripped functions (of any length) using -1, because that’s a >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base >> address for shared libraries, I’d think using it has the potential to >> mislead various consumers.) For .debug_ranges we use -2, because both a >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. >> > >Any harm in using -2 everywhere, for consistency? When resolving a relocation, in certain cases we have to give an undefined symbol a value. This can happen with: * an und...

...ped functions (of any length) using -1, because > > that’s a > > >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base > > >> address for shared libraries, I’d think using it has the potential to > > >> mislead various consumers.) For .debug_ranges we use -2, because both > > a > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > > >> > > > > > >Any harm in using -2 everywhere, for consistency? > > > > When resolving a relocation, in certain cases we have...

...sems somewhat of a heavy handed approach to solving this problem. Alternatively, if we do want to go with something more official then just doing it in a linker using first reloc, why not use sh_info? Seems like it's made for providing an extra information for each section_type. In this case .debug_*. With it we have a current behavior of using names which as far as I can tell the default for figuring out debug sections. If producer provides this extra information the linker can improve layout to help with debug sections overflows, if producer doesn't provide this information, then it'...

...debug info to stripped functions (of any length) using -1, because > that’s a > >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base > >> address for shared libraries, I’d think using it has the potential to > >> mislead various consumers.) For .debug_ranges we use -2, because both > a > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > >> > > > >Any harm in using -2 everywhere, for consistency? > > When resolving a relocation, in certain cases we have to give an undefined > symbol a...

...betaspecs/lsb/LSB-Core-generic/LSB-Core- > generic/ehframechpt.html > > Version > A 1 byte value that identifies the version number of the frame > information structure. This value shall be 1. > > This was introduced by r211272. We should probably be producing 1/3/4 > for .debug_frame, but only 1 for .eh_frame. I expect that truly strict conformance would require that .eh_frame v1 should be emitted as-if DWARF v2, regardless of the DWARF version used for the .debug_* sections. Just for grins I'll point out that the AMD64 ABI specifies that the version field is 1, bu...

...gt; James > > On Tue, 17 Nov 2020 at 07:06, Fāng-ruì Sòng <maskray at google.com> wrote: >> >> 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 input sect...

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 .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X8...

...havior). In long: https://reviews.llvm.org/D81784 and follow-on patches modified the behavior of lld with regards to resolving relocations from debug sections to dead code (either comdat deduplicated, or gc-sections use). A very quick summary of the situation: Original Behavior: - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 elsewhere - gold/lld: 0+addend everywhere Limitations/bugs: - bfd/gold/lld - doesn't support 0 as a valid executable address without ambiguities - gold/lld - ambiguities with large gc'd functions combined with a .te...