search for: dw_form_exprloc

...ncoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) DW_AT_high_pc [DW_FORM_data4] (0x000002b4) DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] = "FB_FPUMP at HORIZONTAL") DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*) DW_ AT_external [DW_FORM_flag_present] (true) In the original object file th...

...DW_AT_name [DW_FORM_strp] ( >> .debug_str[0x0000001d] = "var1") >> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049}) >> DW_AT_external [DW_FORM_flag_present] (true) >> DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0 >> 2e 00 00 00 00 00 00 06 10 00 22 ) >> >> >> Without deref: >> 0x00000032: DW_TAG_variable [2] >> DW_AT_name [DW_FORM_strp] ( >> .debug_str[0x0000001d] = "var1") >> DW_AT_typ...

...0000032: DW_TAG_variable [2] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000001d] = "var1") DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049}) DW_AT_external [DW_FORM_flag_present] (true) DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0 2e 00 00 00 00 00 00 06 10 00 22 ) Without deref: 0x00000032: DW_TAG_variable [2] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000001d] = "var1") DW_AT_type [DW_FORM_ref4] (cu + 0x0048 => {0x00000048})...

..._AT_name [DW_FORM_strp] ( >>> .debug_str[0x0000001d] = "var1") >>> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049}) >>> DW_AT_external [DW_FORM_flag_present] (true) >>> DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0 >>> 2e 00 00 00 00 00 00 06 10 00 22 ) >>> >>> >>> Without deref: >>> 0x00000032: DW_TAG_variable [2] >>> DW_AT_name [DW_FORM_strp] ( >>> .debug_str[0x0000001d] = "var1") >&...

...iable [2] > DW_AT_name [DW_FORM_strp] ( > .debug_str[0x0000001d] = "var1") > DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049}) > DW_AT_external [DW_FORM_flag_present] (true) > DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0 > 2e 00 00 00 00 00 00 06 10 00 22 ) > > > Without deref: > 0x00000032: DW_TAG_variable [2] > DW_AT_name [DW_FORM_strp] ( > .debug_str[0x0000001d] = "var1") > DW_AT_type [DW_FORM_ref4] (cu + 0...

> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Hi, > > I'm trying to achieve the following: > > - I have a global variable BaseAddress that holds the base address of > a contiguous dynamically allocated memory block. > > - I have a number of logical variables of different types that are > mapped on certain address

Hi, I'm trying to achieve the following: - I have a global variable BaseAddress that holds the base address of a contiguous dynamically allocated memory block. - I have a number of logical variables of different types that are mapped on certain address ranges inside the memory block pointed to by BaseAddress. The offset and the size of each such logical variable inside the memory block are

Hi, [ I think I put the most important contributors to the DebugInfo stuff in Cc:. Is there anyone else that I am missing? ] Just a short notice that I am currently working on making llvm-dwarfdump more developer friendly. There are quite a few features in Darwin’s dwarfdump that we find quite useful and that we would like to contribute to llvm-dwarfdump. I have started by augmenting the

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

...gt;getContext().relocMap().end()) { + const std::pair<uint8_t, int64_t> &R = AI->second; + Value.uval = R.second; + *offset_ptr += R.first; + } else + Value.uval = data.getUnsigned(offset_ptr, cu->getAddressByteSize()); + } break; case DW_FORM_exprloc: case DW_FORM_block: @@ -138,9 +147,17 @@ DWARFFormValue::extractValue(DataExtractor data, uint32_t *offset_ptr, case DW_FORM_sdata: Value.sval = data.getSLEB128(offset_ptr); break; - case DW_FORM_strp: - Value.uval = data.getU32(offset_ptr); + case DW_FORM_strp:...

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer