search for: strx

Dear r-help members, I have a number in the form of a string, say: a<-"-01020.909200" I'd like to extract "1020." as well as ".9092" Front<-grep(pattern="[1-9]+[0-9]*\\.", value=TRUE, x=a, fixed=FALSE) End<-grep(pattern="\\.[0-9]*[1-9]+", value=TRUE, x=a, fixed=FALSE) However, both strings give "-01020.909200", exactly

...However, because of the FORM code, we now have whole new worlds of complication regarding where the actual string might be. We might have DW_FORM_strp which puts the actual string in the .debug_string section; eventually we could have DW_FORM_line_str (pointing to .debug_line_str) or even DW_FORM_strx (indirecting through .debug_str_offsets). Conveniently, we have the DWARFFormValue class which knows how to decode data based on what the form code is. Inconveniently, DWARFFormValue assumes it is looking at a .debug_info section, and picks up its relocations from a DWARFUnit. But if we're u...

...I'd mention the idea. I agree it's not worth pursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs that had DW_AT_linkage_name without DW_A...

...icular version(v4 macinfo). For instance, consider this snippet from CLANG: Gen->getCGDebugInfo()->CreateMacro(getCurrentScope(), llvm::dwarf::DW_MACINFO_define, > location, Name.str(), Value.str()). - So, let's say you want to add support for a new form /DW_MACRO_define_strx/, with existing infrastructure, you can't do this without polluting code with lot of if-else. This is just to highlight the problem, there are numerous areas where we will have to add if-else. - DWARF forms[DW_MACINFO*] are unnecessarily hard-coded in CLANG, resulting in...

Yep, Wolfgang picked up on the one thing I saw too. This is why I like having people review my stuff. I think it's a bit of a pity that str_offsets_base can point into the middle of a str_offsets contribution in some ways Actually I changed my mind after saying that in the review, and in this writeup I concluded that it cannot do that. str_offsets_base points to the element immediately

Hello, I'm just start learning R/S-Plus, so I think this 2 doubts is going to be too easy for you... 1) I couldn't discover what is the command for a concatenation of 2 variable strings. 2) For example, if I have three variable strings, and each one has the name of a variable in a data matrix: a<-V1 b<-V2 c<-V3 , is it possible to construct a command like this:

...es a .debug_str_offsets section which has one or more "contributions" in it. Each contribution has a header, which gives its size and whether the array elements are 32 or 64 bits wide. Any DWARF compile-unit or type-unit that uses the array (that is, any unit that uses any of the "strx" forms) has a DW_AT_str_offsets_base attribute that points to the 0th element of the array. The producer chooses whether to have one contribution shared by all units, one contribution per unit, or somewhere in between. There's an implication for how to read the .debug_str_offsets sectio...

...g_abbrev, .debug_addr, .debug_str_offsets. > > .debug_str doesn't need to be fragmented, linkers DTRT already. (linkers deduplicate debug_str - but can they be made to remove unreferenced strings too? in that cas ewe'd have an interesting tradeoff of maybe using FORM_strp rather than strx - if we wanted the linker to be able to drop strings from dropped function definitions, etc) > .debug_macro contents are not tied to functions and won't be fragmented. > > .debug_loclists and .debug_rnglists should be fragmentable the same > way as .debug_info; they exist only as e...

...gt; > > .debug_str doesn't need to be fragmented, linkers DTRT already. > > > > (linkers deduplicate debug_str - but can they be made to remove > > unreferenced strings too? in that cas ewe'd have an interesting > > tradeoff of maybe using FORM_strp rather than strx - if we wanted the > > linker to be able to drop strings from dropped function definitions, > > etc) > > Future refinements are quite possible! > > > > > > .debug_macro contents are not tied to functions and won't be fragmented. > > > > > >...

...eful to make dsymutil/DWARFLinker truly multi-thread? (To make dsymutil/DWARFLinker able to process each object file in a separate thread) >One way to do that would be to have a CU-local type indirection table. >DIEs reference local type numbers (like local address/string numbers - >addrx/strx/rnglistx) and that table contains either sig8 (no linker >fixups required) or the local type offsets you describe - the linker >would then only need to read this type number indirection table and >rewrite them to the final type numbers. Yes, that could be additionally done if this process...

...o invest in solving all the above 1-4 problems and how much community interested in it. Thank you, Alexey. >> >One way to do that would be to have a CU-local type indirection table. >> >DIEs reference local type numbers (like local address/string numbers - >> >addrx/strx/rnglistx) and that table contains either sig8 (no linker >> >fixups required) or the local type offsets you describe - the linker >> >would then only need to read this type number indirection table and >> >rewrite them to the final type numbers. >> >> Yes, tha...

...vm-dwp is the answer to this. DWARFLinker could probably be another answer. Thank you, Alexey. > >> >One way to do that would be to have a CU-local type indirection table. > >> >DIEs reference local type numbers (like local address/string numbers - > >> >addrx/strx/rnglistx) and that table contains either sig8 (no linker > >> >fixups required) or the local type offsets you describe - the linker > >> >would then only need to read this type number indirection table and > >> >rewrite them to the final type numbers. > >&g...

...all the above 1-4 problems and how much community interested in it. > >Thank you, Alexey. > >>> >One way to do that would be to have a CU-local type indirection table. >>> >DIEs reference local type numbers (like local address/string numbers - >>> >addrx/strx/rnglistx) and that table contains either sig8 (no linker >>> >fixups required) or the local type offsets you describe - the linker >>> >would then only need to read this type number indirection table and >>> >rewrite them to the final type numbers. >>> &...

On Fri, Nov 18, 2016 at 10:18 AM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Nov 18, 2016 at 8:43 AM Greg Clayton <gclayton at apple.com> wrote: > > > > On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----Original Message----- > >> From: Greg Clayton

...t; > > > > >Thank you, Alexey. > > > > > >>> >One way to do that would be to have a CU-local type indirection > table. > > >>> >DIEs reference local type numbers (like local address/string > numbers - > > >>> >addrx/strx/rnglistx) and that table contains either sig8 (no linker > > >>> >fixups required) or the local type offsets you describe - the linker > > >>> >would then only need to read this type number indirection table and > > >>> >rewrite them to the fina...

...could probably be another answer. >Ah, fair enough - thanks for the context! > > >> >One way to do that would be to have a CU-local type indirection table. > > >> >DIEs reference local type numbers (like local address/string numbers - > > >> >addrx/strx/rnglistx) and that table contains either sig8 (no linker > > >> >fixups required) or the local type offsets you describe - the linker > > >> >would then only need to read this type number indirection table and > > >> >rewrite them to the final type numbe...

...r answer. >>> Ah, fair enough - thanks for the context! >>>>>>> One way to do that would be to have a CU-local type indirection table. >>>>>>> DIEs reference local type numbers (like local address/string numbers - >>>>>>> addrx/strx/rnglistx) and that table contains either sig8 (no linker >>>>>>> fixups required) or the local type offsets you describe - the linker >>>>>>> would then only need to read this type number indirection table and >>>>>>> rewrite them to th...

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own

>> >> >DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, >> >certainly not when talking about function code. The overhead of a unit occurred only once per >> >translation unit, so that expense was reasonably amortized. >> > >> >Splitting functions into their own object-file sections and making them

...h, fair enough - thanks for the context! >>>>>>>>> One way to do that would be to have a CU-local type indirection table. >>>>>>>>> DIEs reference local type numbers (like local address/string numbers - >>>>>>>>> addrx/strx/rnglistx) and that table contains either sig8 (no linker >>>>>>>>> fixups required) or the local type offsets you describe - the linker >>>>>>>>> would then only need to read this type number indirection table and >>>>>>>&gt...