search for: addr_siz

After an: # ip ru flush I loose all my ip rules but the priority 0 one. root@sarasvati:~# ip ru 0: from all lookup 255 root@sarasvati:~# Ok with that, but now i''m not able to insert any new rule. This leads to a total loose of conectivity. root@sarasvati:~# ip ru add from all table default RTNETLINK answers: Numerical result out of range root@sarasvati:~# ip ru add from all

...------------------------------------------------------------------- > File: out.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "clang version 3.5.0 (209308)" ) > AT_language( DW_LANG_C_plus_plus ) > AT_name( "test.cc <http://test.cc/>" ) > AT...

Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM

...----------------------------------------------- >> File: out.o (x86_64) >> ---------------------------------------------------------------------- >> .debug_info contents: >> >> 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) >> >> 0x0000000b: TAG_compile_unit [1] * >> AT_producer( "clang version 3.5.0 (209308)" ) >> AT_language( DW_LANG_C_plus_plus ) >> AT_name( "test.cc <http://test.cc/>" )...

...DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000051] = "int") DW_AT_encoding [DW_FORM_data1] (0x05) DW_AT_byte_size [DW_FORM_data1] (0x04) 0x00000058: NULL 0x000001ec: Compile Unit: length = 0x0000002b version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0000021b) 0x0000000b: DW_TAG_type_unit [25] * DW_AT_language [DW_FORM_data2] (0x0004) 0x0000000e: DW_TAG_namespace [9] * It is a bit weird using the same syntax to print the section relative offest for the unit header, then unit-relative offsets for the...

...the default settings ---------------------------------------------------------------------- File: out.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) 0x0000000b: TAG_compile_unit [1] * AT_producer( "clang version 3.5.0 (209308)" ) AT_language( DW_LANG_C_plus_plus ) AT_name( "test.cc<http://test.cc/>" ) AT_stmt_list( 0x00000000 )...

...iated! Thanks, -matt ---------------------------------------------------------------------- File: a.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x00000043 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000047) 0x0000000b: TAG_compile_unit [1] * AT_producer( "volta" ) AT_language( DW_LANG_C99 ) AT_name( "a.c" ) AT_entry_pc( 0x0000000000000000 ) AT_stmt_list( 0x00000000 ) AT_c...

...its AT_location. --- ---------------------------------------------------------------------- File: foo.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x000000a9 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x000000ad) 0x0000000b: TAG_compile_unit [1] * AT_producer( "clay compiler 0.1git" ) AT_language( Unknown DW_LANG constant: 0xc1a4 ) AT_name( "foo.clay" ) AT_entry_pc( 0x0000000000000000 ) AT_...

Hello, I Have a question related to the RT check on pointers during Loop Access Analysis pass. There is a testcase with loop code that consist of 4 different memory operations referring two global objects of different address spaces. One from global constant (address space 4, addr_size = 64) and the other from local, LDS (address space 3, addr_size= 32). (Details of various address spaces available for AMDGPU backend: https://llvm.org/docs/AMDGPUUsage.html#address-spaces) With upstream compiler, the testcase fails with a crash (given at the end of the e-mail) in the opt while t...

...mulate_cmpxchg, - .cmpxchg8b = pv_emulate_cmpxchg8b, + .cmpxchg2 = pv_emulate_cmpxchg8b, }; struct x86_emulate_ops *shadow_init_emulation( @@ -390,7 +398,12 @@ struct x86_emulate_ops *shadow_init_emul if ( !is_hvm_vcpu(v) ) { +#ifndef CONFIG_COMPAT sh_ctxt->ctxt.addr_size = sh_ctxt->ctxt.sp_size = BITS_PER_LONG; +#else + sh_ctxt->ctxt.addr_size = sh_ctxt->ctxt.sp_size = + !is_pv_32on64_vcpu(v) ? BITS_PER_LONG : COMPAT_BITS_PER_LONG; +#endif return &pv_shadow_emulator_ops; } Index: 2008-04-15/xen/arch/x86/mm/shadow/mult...

...t; On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000049) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "julia" ) > AT_language( DW_LANG_C89 ) > AT_name( "string.jl" ) > AT_stmt_list( 0x00000000 ) > AT_comp_di...

...--------------------------------------------------------------- >  File: foo.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x000000a9  version = 0x0002  abbr_offset > = 0x00000000  addr_size = 0x08  (next CU at 0x000000ad) > > 0x0000000b: TAG_compile_unit [1] * >              AT_producer( "clay compiler 0.1git" ) >              AT_language( Unknown DW_LANG constant: 0xc1a4 ) >              AT_name( "foo.clay" ) >              AT_entry_pc( 0x000000...

Hi all, I've put this email in a different thread, although it is quite similar to some of the threads on tombstoning etc, with similar underlying structural issues. Whilst prototyping my fragmented DWARF idea for GC-ing DWARF sections properly, I ran into an object in the game code I was using as my input where a v4 .debug_loc section had a location description that looked something like

...x01 ) > 0x000000d7: AT_low_pc( 0x0000f780 ) > 0x000000db: AT_high_pc( 0x0000f7b1 ) > 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) > > 0x000000e1: NULL > > 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 > abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) > > 0x000000ed: TAG_compile_unit [1] * > 0x000000ee: AT_producer( .debug_str[0x00000001] = "0.1 tartc" ) > 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) > 0x000000f4: AT_name( .debug_str[0x000001fa] = "range.tart" ) > 0x000...

...( ) ) 0x000000d6: AT_external( 0x01 ) 0x000000d7: AT_low_pc( 0x0000f780 ) 0x000000db: AT_high_pc( 0x0000f7b1 ) 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) 0x000000e1: NULL 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) 0x000000ed: TAG_compile_unit [1] * 0x000000ee: AT_producer( .debug_str[0x00000001] = "0.1 tartc" ) 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) 0x000000f4: AT_name( .debug_str[0x000001fa] = "range.tart" ) 0x000000f8: AT_entry_pc( 0x000043...

...ort to x86_emulate. I construct the x86_emulate_ctxt and reuse the "ptwr_emulate_ops". code like this: extern const struct x86_emulate_ops ptwr_emulate_ops; in do_general_protection { .... struct x86_emulate_ctxt ctxt; ctxt.regs = regs; ctxt.force_writeback = 1; // 0 is the same ctxt.addr_size = 32; ctxt.sp_size = 32; ret = x86_emulate(&ctxt, &ptwr_emulate_ops); ... } the error message is: (XEN) mm.c:5235:d0 ptwr_emulate: bad access (cr2=553a4000, addr=e81b5fac, bytes=4) I have another idea, I directly update the stack and change the EIP and ESP like this: regs->esp...

....org>> έγραψε: Hello, I Have a question related to the RT check on pointers during Loop Access Analysis pass. There is a testcase with loop code that consist of 4 different memory operations referring two global objects of different address spaces. One from global constant (address space 4, addr_size = 64) and the other from local, LDS (address space 3, addr_size= 32). (Details of various address spaces available for AMDGPU backend: https://llvm.org/docs/AMDGPUUsage.html#address-spaces<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fllvm.org%2Fdocs%2FAMDGPUUsage.html%23add...

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

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

...---------------------------------------------------------------------- > File: a.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x00000043 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000047) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "volta" ) > AT_language( DW_LANG_C99 ) > AT_name( "a.c" ) > AT_entry_pc( 0x0000000000000000 ) > AT_stmt_list(...