similar to: DWARF .debug_aranges data objects and address spaces

On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <paul.robinson at sony.com> wrote: > With AVR being affected, upstreaming a patch to put segment selectors into > .debug_aranges becomes completely reasonable. There would likely want to > be a target hook somewhere to return a value saying what size to use, with > the default implementation returning zero. > *nod* something

On Mon, Mar 16, 2020 at 10:50 AM Robinson, Paul <paul.robinson at sony.com> wrote: > SCE tuning does turn on the .debug_aranges section. Our debugger team > really cares about startup cost. Turnaround time in general is huge for our > licensees, to the point where we support edit-and-continue (minimal > rebuild, live-patch the running process). > Ah, good to know! I'd

I’ve encountered this kind of architecture before, a long time ago (academically). In a flat-address-space machine such as X64, there is still an instruction/data distinction, but usually only down at the level of I-cache versus D-cache (instruction fetch versus data fetch). A Harvard architecture machine exposes that to the programmer, which effectively doubles the available address space.

On Thu Mar 12, 2020 at 5:37 PM, David Blaikie wrote: > On Wed, Mar 11, 2020 at 8:09 AM Luke Drummond > <luke.drummond at codeplay.com> > wrote: > > > On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote: > > > If you only want code addresses, why not use the CU's > > > low_pc/high_pc/ranges > > > - those are guaranteed to be only code

I'm not across most of this debug info stuff but I'll stomp in here to confirm that AVR is a Harvard architecture, with separate addressing for the data and program buses via specialized instructions which will load from either one, or the other, but never both. It makes sense that this particular problem would also affect AVR - the backend does have some issues with debug info

On Tue Mar 10, 2020 at 7:45 PM, David Blaikie wrote: > If you only want code addresses, why not use the CU's > low_pc/high_pc/ranges > - those are guaranteed to be only code addresses, I think? > In the common case, for most targets LLVM supports I think you're right, but for my case, regrettably, not. Because my target is a Harvard Architecture, any code address can have the

Hi, I just updated from r190763 to r191137 and started getting failures in generated assembly language when debug info is enabled. Here is the test case: // Compile and run for every target. // RUN: %ecc -g -o %t %s && %t // FAIL: %armecc -g -o %t %s && %armrun %t // FAIL: %armebecc -g -o %t %s && %armebrun %t // RUN: %i386ecc -g -o %t %s && %i386run %t // FAIL:

Interesting. File please? Thanks. On Sep 21, 2013 6:01 AM, "Richard Pennington" <rich at pennware.com> wrote: > Hi, > > I just updated from r190763 to r191137 and started getting failures in > generated assembly language when debug info is enabled. Here is the test > case: > > // Compile and run for every target. > // RUN: %ecc -g -o %t %s && %t

If it thinks the symbol is in the BSS section, then it should never have tried to use .comm to emit it I think. On x86 it does not try to mix and match, which is why it works. AFAIK comm symbols are regarded as having no section, rather than being bss, so I think it's a bug in whatever code printed that .comm statement. I'll look into this tomorrow. > Eric Christopher

On 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)

Hi, In the code below I create a small data.frame (dat) and then cut it into different groups using CutList. The lists in CutList allow to me choose whatever columns I want from dat and allow me to cut it into any number of groups by changing the lists. It seems to work OK but when I'm done I have a variable number of data frames what I need to do further operations on and I don't know

Another example would be .debug_pubnames and .debug_pubtypes sections. Currently these default to omitted for Darwin and PS4, but included everywhere else. My initial patch for "tuning" changes the PS4 platform criterion to the SCE debugger predicate; quite likely the "not Darwin" criterion ought to be "not LLDB" or in other words "on for GDB only."

> A few more things that vote for debugger tuning: > > - LLDB doesn't like to have DWARF that has a class A that inherits from > class B, but only a forward declaration of class B is provided. Hmm do we emit that kind of thing today? In a naïve test, I'm seeing the full description of class B. > - LLDB wants the .apple_XXX accelerator tables, GDB wants >

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.

On 01.09.2020 20:07, David Blaikie wrote: > Fair enough - thanks for clarifying the differences! (I'd still lean a > bit towards this being dwz-esque, as you say "an extension of classic dwz" I doubt a little about "llvm-dwz" since it might confuse people who would expect exactly the same behavior. But if we think of it as "an extension of classic dwz" and

This is basically a reboot of the previous thread titled About the "debugger target" except that "target" was really too strong a term for what I had intended to use this feature for. "Debugger tuning" is more like it. You don't need to have read the previous thread, I'll recap here. Fundamentally, Clang/LLVM uses DWARF as the specification for the

> On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com> wrote: > > >> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >> >>> A few more things that vote for debugger tuning: >>> >>> - LLDB doesn't like to have DWARF that has a class A that inherits from >>> class B, but

On 02.09.2020 21:44, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 01.09.2020 20:07, David Blaikie wrote: >> Fair enough - thanks for clarifying the differences! (I'd still >> lean a bit towards this being dwz-esque, as you say "an

> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > > > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com <mailto:gclayton at apple.com>> wrote: > > > > > >> On May 1,