search for: str_offset

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 after the header. You can have multiple units sharing...

...eger (for type DWORD) + * or an offset into the PACKED_REGISTRY_TABLE (for types BINARY and STRING). + * + * All memory allocated by add_registry() is released. + */ +static void build_registry(struct nvkm_gsp *gsp, PACKED_REGISTRY_TABLE *registry) +{ + struct registry_list_entry *reg, *n; + size_t str_offset; + unsigned int i = 0; + + registry->numEntries = list_count_nodes(&gsp->registry_list); + str_offset = struct_size(registry, entries, registry->numEntries); + + list_for_each_entry_safe(reg, n, &gsp->registry_list, head) { + registry->entries[i].type = reg->type; + regi...

...nated string for entry 1| + * +----------------------------------+ + * ... (one copy for each entry) + * + * All memory allocated by add_registry() is released. + */ +static void build_registry(struct nvkm_gsp *gsp, PACKED_REGISTRY_TABLE *registry) +{ + struct registry_list_entry *reg, *n; + size_t str_offset; + unsigned int i = 0; + + registry->numEntries = list_count_nodes(&gsp->registry_list); + str_offset = struct_size(registry, entries, registry->numEntries); + + list_for_each_entry_safe(reg, n, &gsp->registry_list, list) { + registry->entries[i].type = reg->type; + regi...

...a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -1078,7 +1078,6 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp) if (IS_ERR(rpc)) return PTR_ERR(rpc); - rpc->size = sizeof(*rpc); rpc->numEntries = NV_GSP_REG_NUM_ENTRIES; str_offset = offsetof(typeof(*rpc), entries[NV_GSP_REG_NUM_ENTRIES]); @@ -1094,6 +1093,7 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp) strings += name_len; str_offset += name_len; } + rpc->size = str_offset; return nvkm_gsp_rpc_wr(gsp, rpc, false); } -- 2.43.0

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pieb, > Wolfgang via llvm-dev > Sent: Wednesday, July 05, 2017 6:14 PM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [DWARFv5] Reading the .debug_str_offsets section > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > > Robinson, Paul via llvm-dev > > Sent: Wednesday, July 05, 2017 1:35 PM > > To: llvm-dev at lists.llvm.org > > Subject: [llvm-dev] [DWARFv...

...m/nouveau/nvkm/subdev/gsp/r535.c index 9994cbd6f1c4..9858c1438aa7 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -1112,7 +1112,7 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp) rpc->numEntries = NV_GSP_REG_NUM_ENTRIES; str_offset = offsetof(typeof(*rpc), entries[NV_GSP_REG_NUM_ENTRIES]); - strings = (char *)&rpc->entries[NV_GSP_REG_NUM_ENTRIES]; + strings = (char *)rpc + str_offset; for (i = 0; i < NV_GSP_REG_NUM_ENTRIES; i++) { int name_len = strlen(r535_registry_entries[i].name) + 1; -- 2.34.1

.../gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index dc44f5c7833f..228335487af5 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -1048,7 +1048,7 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp) char *strings; int str_offset; int i; - size_t rpc_size = sizeof(*rpc) + sizeof(rpc->entries[0]) * NV_GSP_REG_NUM_ENTRIES; + size_t rpc_size = struct_size(rpc, entries, NV_GSP_REG_NUM_ENTRIES); /* add strings + null terminator */ for (i = 0; i < NV_GSP_REG_NUM_ENTRIES; i++) -- 2.34.1

...nouveau/nvkm/subdev/gsp/r535.c > index dc44f5c7833f..228335487af5 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c > @@ -1048,7 +1048,7 @@ r535_gsp_rpc_set_registry(struct nvkm_gsp *gsp) > char *strings; > int str_offset; > int i; > - size_t rpc_size = sizeof(*rpc) + sizeof(rpc->entries[0]) * NV_GSP_REG_NUM_ENTRIES; > + size_t rpc_size = struct_size(rpc, entries, NV_GSP_REG_NUM_ENTRIES); > > /* add strings + null terminator */ > for (i = 0; i < NV_GSP_REG_NUM_ENTRIES; i++) > -- &...

...iple DWO files stacked together - mostly to deduplicate strings and type units as a sort of archival (like dsym) format. The way DWPs work, roughly (full/more details here: https://gcc.gnu.org/wiki/DebugFissionDWP ) is that all the sections are concatenated together, except the debug_str and debug_str_offsets sections which have special handling to do what you'd expect - deduplicate strings, and adjust the str_offsets to point to the right offsets in the deduplicated string section. The other thing that DWP has, is an index, or two. cu_index and tu_index. We'll just look at cu_index. A cu_ind...

On Mon, Feb 29, 2016 at 03:47:49PM -0800, David Blaikie wrote: > On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > Hi David, > > > > The way I imagined that we might want to extend the MCStreamer API (this > > was motivated by DIEData) is by allowing clients to move bytes and fixups > > into the MC layer. >

...type units as a sort of archival (like dsym) format. >> >> The way DWPs work, roughly (full/more details here: https://gcc.gnu.org/wiki/DebugFissionDWP <https://gcc.gnu.org/wiki/DebugFissionDWP> ) is that all the sections are concatenated together, except the debug_str and debug_str_offsets sections which have special handling to do what you'd expect - deduplicate strings, and adjust the str_offsets to point to the right offsets in the deduplicated string section. >> >> The other thing that DWP has, is an index, or two. cu_index and tu_index. We'll just look at c...

On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi David, > > The way I imagined that we might want to extend the MCStreamer API (this > was motivated by DIEData) is by allowing clients to move bytes and fixups > into the MC layer. > > This is the sort of API that I was imagining: > > void

...iple DWO files stacked together - mostly to deduplicate strings and type units as a sort of archival (like dsym) format. The way DWPs work, roughly (full/more details here: https://gcc.gnu.org/wiki/DebugFissionDWP ) is that all the sections are concatenated together, except the debug_str and debug_str_offsets sections which have special handling to do what you'd expect - deduplicate strings, and adjust the str_offsets to point to the right offsets in the deduplicated string section. The other thing that DWP has, is an index, or two. cu_index and tu_index. We'll just look at cu_index. A cu_ind...

...NULL; Elf32_Shdr *crt_sht; Elf32_Off buff_offset; @@ -100,8 +100,8 @@ static int load_shallow_sections(struct elf_module *module, Elf32_Ehdr *elf_hdr) // Setup module information module->module_size = max_offset - min_offset; - module->str_table = (char*)(module->module_addr + (str_offset - min_offset)); - module->sym_table = module->module_addr + (sym_offset - min_offset); + module->str_table = (char *)module->module_addr + (str_offset - min_offset); + module->sym_table = (char *)module->module_addr + (sym_offset - min_offset); out: // Release the SHT diff --...

So Dehao and I have been dealing with some of the nitty gritty details of debug info with ThinLTO, specifically with Fission(Split DWARF). This applies to LTO as well, so I won't single out ThinLTO here. 1) Multiple CUs in a .dwo file Clang/LLVM produces a CU for each original source file - these CUs are kept through IR linking (thin or full) and produced as distinct CUs in the resulting