search for: lowpc

...>Personally I'd vote for -1, and make pre-v5 .debug_loc/.debug_ranges >sections be an extra-special case using -2. We can (I hope) standardize >on -1 for v6 onward, and document -1/-2 on the DWARF wiki as recommended >practice for prior versions. Would it make sense to use "LowPC > HighPC" in DWARF documentation as a sign for that case, instead of -1 or -2 ? Or more correct: To indicate that address range points into deleted code there should be used either zero length, either LowPC>HighPc range ? zero length address range is already defined in DWARF documenta...

...on.c +@@ -61,6 +61,7 @@ + static char sccsid[] = "@(#)gmon.c 5.3 (Berkeley) 5/22/91"; + #endif /* not lint */ + ++#include <string.h> + #define DEBUG + #ifdef DEBUG + #include <stdio.h> +@@ -89,7 +90,7 @@ static int s_scale; + + extern int errno; + +-int ++void + monstartup(lowpc, highpc) + char *lowpc; + char *highpc; +@@ -341,6 +342,7 @@ overflow: + * profiling is what mcount checks to see if + * all the data structures are ready. + */ ++void + moncontrol(mode) + int mode; + {

...DwarfFile. 4. split DWARF support. This solution does not work with split DWARF currently. But it could be useful for the split dwarf in two ways: a) The generation of skeleton file could be changed in such a way that address ranges pointing to garbage collected code would be replaced with lowpc=0, highpc=0. That would solve the problem of overlapping address ranges(D59553). b) The approach similar to dsymutil implementation could be used to generate monolithic debuginfo created from .dwo files. That suggestion is from - https://reviews.llvm.org/D74169#1888386. i.e., DWARFLinker...

On Thu, May 28, 2020 at 6:03 AM Alexey Lapshin <alapshin at accesssoftek.com> wrote: > Hi David, > > > >So there have been several recent discussions about the issues around > > >DWARF-agnostic linking and gc-sections, linkonce function definitions > being > > >dropped, etc - and just how much DWARF-awareness would be suitable > > >in a linker to

...support. >> This solution does not work with split DWARF currently. But it could be useful for the split dwarf in two ways: >> a) The generation of skeleton file could be changed in such a way that address ranges pointing to garbage >> collected code would be replaced with lowpc=0, highpc=0. That would solve the problem of overlapping >> address ranges(D59553). >This wouldn't/couldn't completely address the issue - because some address ranges would be in the .dwo files >the linker can't see - and they'd still end up with the interesting addre...

...(split and non-split) to signal certain addresses point to dead code with a > specific blessed value that linkers would need to implement - because with Split DWARF there's > no way to solve the non-CU addresses at the linker. I think the worthful solution for that signal value would be LowPC > HighPC. That does not require additional bits in DWARF. It would be natural to skip such address ranges since they explicitly marked as invalid. It could be implemented in a linker very easily. Probably, it would make sense to describe that usage in DWARF standard. As to the addresses which a...

...resses point to dead code with a > > > specific blessed value that linkers would need to implement - because > with Split DWARF there's > > > no way to solve the non-CU addresses at the linker. > > > > I think the worthful solution for that signal value would be LowPC > > HighPC. > > That does not require additional bits in DWARF. > > It would be natural to skip such address ranges since they explicitly > marked as invalid. > > It could be implemented in a linker very easily. Probably, it would make > sense to describe that > &gt...

...; > > specific blessed value that linkers would need to implement - because > >> with Split DWARF there's > >> > > no way to solve the non-CU addresses at the linker. > >> > > >> > I think the worthful solution for that signal value would be LowPC > > >> HighPC. > >> > That does not require additional bits in DWARF. > >> > It would be natural to skip such address ranges since they explicitly > >> marked as invalid. > >> > It could be implemented in a linker very easily. Probably, it wo...

...it) to signal certain addresses point to dead code with a > > specific blessed value that linkers would need to implement - because with Split DWARF there's > > no way to solve the non-CU addresses at the linker. > > I think the worthful solution for that signal value would be LowPC > HighPC. > That does not require additional bits in DWARF. > It would be natural to skip such address ranges since they explicitly marked as invalid. > It could be implemented in a linker very easily. Probably, it would make sense to describe that > usage in DWARF standard. > &gt...

On 2020-05-28, David Blaikie wrote: >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> >wrote: > >> As has been mentioned elsewhere, Sony generally fixes up references 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 >>

...n addresses point to dead code with a > > > specific blessed value that linkers would need to implement - because with Split DWARF there's > > > no way to solve the non-CU addresses at the linker. > > > > I think the worthful solution for that signal value would be LowPC > HighPC. > > That does not require additional bits in DWARF. > > It would be natural to skip such address ranges since they explicitly marked as invalid. > > It could be implemented in a linker very easily. Probably, it would make sense to describe that > > usage in DWAR...

...n addresses point to dead code with a > > > specific blessed value that linkers would need to implement - because with Split DWARF there's > > > no way to solve the non-CU addresses at the linker. > > > > I think the worthful solution for that signal value would be LowPC > HighPC. > > That does not require additional bits in DWARF. > > It would be natural to skip such address ranges since they explicitly marked as invalid. > > It could be implemented in a linker very easily. Probably, it would make sense to describe that > > usage in DWAR...

...dead code with a > > > > specific blessed value that linkers would need to implement - because with Split DWARF there's > > > > no way to solve the non-CU addresses at the linker. > > > > > > I think the worthful solution for that signal value would be LowPC > HighPC. > > > That does not require additional bits in DWARF. > > > It would be natural to skip such address ranges since they explicitly marked as invalid. > > > It could be implemented in a linker very easily. Probably, it would make sense to describe that > &gt...

...t; > > > > specific blessed value that linkers would need to implement - because with Split DWARF there's > > > > > no way to solve the non-CU addresses at the linker. > > > > > > > > I think the worthful solution for that signal value would be LowPC > HighPC. > > > > That does not require additional bits in DWARF. > > > > It would be natural to skip such address ranges since they explicitly marked as invalid. > > > > It could be implemented in a linker very easily. Probably, it would make sense to describ...

...t; > specific blessed value that linkers would need to implement - because with Split DWARF there's > > > > > > no way to solve the non-CU addresses at the linker. > > > > > > > > > > I think the worthful solution for that signal value would be LowPC > HighPC. > > > > > That does not require additional bits in DWARF. > > > > > It would be natural to skip such address ranges since they explicitly marked as invalid. > > > > > It could be implemented in a linker very easily. Probably, it would make s...

...> > specific blessed value that linkers would need to implement - because with Split DWARF there's >> > > > > no way to solve the non-CU addresses at the linker. >> > > > >> > > > I think the worthful solution for that signal value would be LowPC > HighPC. >> > > > That does not require additional bits in DWARF. >> > > > It would be natural to skip such address ranges since they explicitly marked as invalid. >> > > > It could be implemented in a linker very easily. Probably, it would make sens...

...inkers would need to implement - > because with Split DWARF there's > > >> > > > > no way to solve the non-CU addresses at the linker. > > >> > > > > > >> > > > I think the worthful solution for that signal value would be > LowPC > HighPC. > > >> > > > That does not require additional bits in DWARF. > > >> > > > It would be natural to skip such address ranges since they > explicitly marked as invalid. > > >> > > > It could be implemented in a linker very e...

...c blessed value that linkers would need to implement - because with Split DWARF there's > > > > > > > no way to solve the non-CU addresses at the linker. > > > > > > > > > > > > I think the worthful solution for that signal value would be LowPC > HighPC. > > > > > > That does not require additional bits in DWARF. > > > > > > It would be natural to skip such address ranges since they explicitly marked as invalid. > > > > > > It could be implemented in a linker very easily. Probably,...

...t; > > specific blessed value that linkers would need to implement - > > because with Split DWARF there's > > > > > no way to solve the non-CU addresses at the linker. > > > > > > > > I think the worthful solution for that signal value would be LowPC > > > HighPC. > > > > That does not require additional bits in DWARF. > > > > It would be natural to skip such address ranges since they explicitly > > marked as invalid. > > > > It could be implemented in a linker very easily. Probably, it would &...

...;>>>> specific blessed value that linkers would need to implement - because with Split DWARF there's >>>>>>>>> no way to solve the non-CU addresses at the linker. >>>>>>>> I think the worthful solution for that signal value would be LowPC > HighPC. >>>>>>>> That does not require additional bits in DWARF. >>>>>>>> It would be natural to skip such address ranges since they explicitly marked as invalid. >>>>>>>> It could be implemented in a linker very easily. P...