Lines Matching +refs:po +refs:guess +refs:team +refs:address
328 Given the introduction of the new address operand types for rcpc3
335 The particular choices of address indexing, along with their encoding
364 aarch64: rcpc3: Define address operand fields and inserter/extractors
366 the address base register for load/stores, it is necessary to specify
367 the data register addressing mode and whether the address register is
373 address operand insertion in assembly and another for extraction in
404 the address operand in the OPNDS operand list argument.
803 register is updated with the result of the address calculation: before
1707 the PC decrease but the symbol address to remain unchanged due to section
2165 But the pc address (as well as the file name and line number) is missing for
2407 unrelocated address. This patch changes the interface to use the
2437 f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"),
3237 MAINTAINERS: Update my email address
3759 ^Z^Zframe-address^M
3761 ^Z^Zframe-address-end^M
3800 4) Check out */po/*.pot which we don't update frequently.
3804 Synchronize config.sub and config.guess with their upstream master versions.
3809 …commit e4786449e1c26716e3f9ea182caf472e4dbc96e0 config.guess: invoke "uname -p" from PATH for n…
3810 …commit 021155df7fad97a5ae1baa354e15a03ea14500b4 config.guess: Detect Android (as opposed to GNU…
3815 …commit af8d803a82436779d35ea389888788c78677804e config.guess (aarch64:Linux:*:*): Detect 32-bit…
4261 searches for the epilogue address will only find the last address that
4568 MAINTAINERS: Update my email address
5886 as to which address this code is using.
6071 become re-usable. Besides the addition to address the first issue, that
6304 sim: ppc: phb: add missing break to address decoder
6353 the same size as an address on the target system.
7263 (MEMORY): Use as start address for the text region.
7301 (gdb) info address i
7303 Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0
7744 the code for string handling writes the address fetching callback
8126 uint64_t's, which I guess is fine because it is expected that native
8522 Please contact the application's support team for more information.
8602 address materialization. For example, the AArch64's psABI allows
8608 address from the GOT. The pseudo instruction is expanded to auipc+ld.
8609 If the address loaded by the instruction pair is actually a PC-relative
8850 And the TEM value at the value address was created with the
9185 command. I guess there's no reason why we couldn't allow component
9356 from_index=<error reading variable: Cannot access memory at address 0x0>
9559 Cannot access memory at address 0x3dbf4120
9561 Cannot access memory at address 0x77644120
10180 argument value into an address if it is assumed to be a PC-relative
10484 gdb: Update Petr Tesarik's email address in gdb/MAINTAINERS
11726 - a program space with an address space is created
11729 returns false, and no new address space is created
11730 - a second program space with the same address space is created
11733 false, and the address space is deleted
11734 - when gdb uses the address space of the remaining program space, we run into
11735 the segfault, because the address space is deleted.
11741 For now, prevent the segmentation fault by making the address space a refcounted
11746 A better solution might be to have the address spaces be reference counted
12598 symbol as address and hence causing runtime issues. Refuse to assemble
12781 In 31-bit addressing mode the address computation using those large
12786 In 64-bit addressing mode the address computation using those large
13549 Patch 743877128 ("gdb: remove regcache's address space") changed the
13803 Cannot access memory at address 0xf77c6a7c^M
13897 r3 contains the address of where the data structure to be returned is to
14250 gdb: remove regcache's address space
14251 While looking at the regcache code, I noticed that the address space
14255 way of getting the address space for a thread, if you already have the
14256 regcache. But there is always another way to get the address space, as
14258 The regcache code itself doesn't use the address space.
14267 there might have been the intention of supporting per-thread address
14270 address space from a ptid (because constructing a regcache required an
14271 address space), and this seemed like the right way to do it, I don't
14277 the inferior's address space. And thread_address_space is only used in
14280 assume that it's fine to use the inferior's address space everywhere.
14281 Callers of regcache::aspace are updated to get the address space from
14287 - remove everything in regcache related to address spaces
14292 - adjust all users of regcache::aspace to get the address space another
15333 breakpoints where one of them was at address 0.
15342 accept either location as correct provided the breakpoint address is not
15346 or function caller and fails if the breakpoint address is 0x0. The line
16165 software breakpoint at this address, then the current behaviour is
16185 syscall if there is a breakpoint at the syscall address.
16192 + GDB removes s/w breakpoint at syscall address,
16255 for the new/child thread. That would be sufficient to address in-line
16509 consider falling back to a previous possible start address in
16704 (Qt5WebEngine) didn't build anymore on x86 32bit due to address
16705 space limits. It barely fit into address space before the new
17114 space ready to start typing the address to disassemble at:
17135 Note that the 'disassemble' command's address arguments are specified
17170 'hello.c':: but I guess this is a limitation of the current
17266 * po/bfd.pot: Regenerate.
17281 * po/bfd.pot: Regenerate.
17295 * po/bfd.pot: Regenerate.
17447 When compiling gdb with -fsanitize=address on ARM, I get a crash in test
17453 …==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0…
17472 0x549 is the address of the test_call_subr label, 0x548, with the thumb
17473 bit enabled. Before doing some math with the address, I think we need
17478 return an address that is suitable for arithmetic. In any case, that
17653 gdb: Update email address for Carl Love in gdb/MAINTAINERS
17699 …an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures s…
17818 I guess that many functions could be marked as nodiscard, essentially
18511 reading inferior memory based on gdb.Value.address and
18513 don't always have an address.
19683 before using it to calculate destination address.
19738 The problem is that commit c96ceed9dce ("gdb: include the end address in
19798 gdb: include the end address in in-memory bfd filenames
19801 66984afd29e gdb: include the base address in in-memory bfd filenames
19803 added the base address to in-memory bfd filenames. Also add the end
19804 address to allow dumping the in-memory bfd using the 'dump memory'
20047 Only allow closure lookup by address if there are threads displaced-stepping
20050 is available whenever we have a match between the provided address argument and
20051 the buffer address.
20095 current_thread and if the buffer address matches the address argument.
20941 extend-to-32bit-address conditions"). This may or may not be a gas regression
21299 with newline handling which I'll address in a later commit.
21714 Problem #1 I'm just ignoring for now, I guess at some point we might
21728 So, we would have to choose; delete the address space or not. If we
21729 delete it on error, then we might delete an address space that is
21730 shared within another program space. If we don't delete the address
21733 A better solution might be to have the address spaces be reference
21736 the address space when appropriate.
21895 Start address 0x0000000000401050, load size 2004
22008 import, I guess it should be updated to call error() maybe, but I'm
22104 microblaze: Add address extension instructions
22106 …* microblaze-opc.h (MAX_OPCODES): Increase to 300. (op_code_struct): Add address extension instruc…
22282 The former, although more correct, doesn't address the case of existing gdb's
22324 To address this, fetch the thread's architecture before dumping its register
22783 …* dwarf.c (fetch_indexed_value): Delete. (fetch_indexed_offset): Correct base address calculation.…
23124 1. DT_X86_64_PLT: The address of the procedure linkage table.
23308 to) display the disassembly for address 0, which led to the gdb segfault.
23767 to infer ("guess") the size of the XSAVE register set that the Linux
23770 for this guess earlier was just not the best guess. In the case that
23784 Fix: nm: SEGV on unknow address at nm.c:718 in print_symname
24002 x86-64: fix suffix-less PUSH of symbol address
24005 In 5cc007751cdb ("x86: further adjust extend-to-32bit-address
24028 pcaddi has a 20-bit signed immediate, it can address a +/- 2MB pc relative
24029 address, and the address should be 4-byte aligned.
24297 …p_attribute): New function. (read_bases): Read and reccord all range and address bases in a CU. (p…
24734 and the relative address in the branch instruction. Remove unused code.
24822 set on a raw address will have only the "address" field populated, but
24830 address are still included.
25293 - S is the base address of the symbol in the memory
25536 CORE_ADDR sized entries to the address pointed to by 'saved', this is
25763 While there also address a related anomaly: Disabling AES but neither
25956 The register that GDB calls fioff normally contains the address of the
25965 the fioff register contains the address of the FLD1 instruction.
25984 Linux, from what I saw), the "last instruction address" register (or
26054 x87 to want to print the "x87 last instruction address", and have no
26289 File name Line number Starting address View Stmt
26314 File name Line number Starting address View Stmt
26810 Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
26811 Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
26816 Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
26911 may print as "0x0" or as an address with a symbol name following.
26913 tests that assume it always prints as an ordinary address in backtrace
26918 address string being shorter or longer than a regular address.
28244 Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
28251 The instruction at this address is:
29061 what I've chosen to address to fix this issue, following what is done
29406 padding is added before pi to show that the actual address of pi and
29619 extended also address the issue for MI too.
29761 To address this I've reworked the message that is printed to include
29885 thread. To address that, this commits adds a delete_thread_with_code
30820 vfork, when two processes are sharing the same address space.
30891 (po/SRC-POTFILES.in): uniq SRC_POTFILES.
30892 (po/BLD-POTFILES.in): uniq BFD_POTFILES.
30894 * po/Make-in (bfd.pot): Edit out source dir from comments.
30895 * po/SRC-POTFILES.in: Regenerate.
30899 * po/POTFILES.in: Regenerate.
31410 path, this should still address the issue seen in b1e0126ec56e,
31940 If ADDRESS is provided, dump only the file for that address.
31952 If ADDRESS is provided, dump only the file for that address.
31962 the symbols for the file with code at that address".
33120 The frame command on Power pc prints the address in hex between the
33128 The printing of the address for the frame is done by function
33131 address. Currently, SAL.IS is false on PowerPC and true on X86-64.
33133 Update the set re string to accept the hex address if it exits.
33298 …[breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main a…
33299 [breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5
33300 [breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e
33301 [breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4
33302 …[breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main …
33303 …[breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to …
33304 …[breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to …
33305 …[breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to …
34790 CFLAGS="-m32 -g -O2 -fsanitize=address,undefined".
35052 * Don't use the address of a variable as its memoryReference -- only
35993 ….../ld/testsuite/ld-mips-elf/mips16-local-stubs-1.s:16: Warning: la used to load 64-bit address; r…
36025 ….../gas/testsuite/gas/mips/fix-rm7000-2.s:11: Warning: la used to load 64-bit address; recommend u…
36027 or pattern dump mismatches against 32-bit address calculations, however
36284 ldscripts/empty-address vs. xcoff
36285 The empty-address tests check that if a section is removed by ld due
36288 created by empty-address-2* and empty-address-3* for some reason, and
36291 * testsuite/ld-scripts/empty-address-1.d: Accept more symbols.
36292 * testsuite/ld-scripts/empty-address-2a.d: xfail for xcoff.
36293 * testsuite/ld-scripts/empty-address-2b.d: Likewise.
36294 * testsuite/ld-scripts/empty-address-3a.d: Likewise.
36295 * testsuite/ld-scripts/empty-address-3b.d: Likewise.
37420 makes it easy to find the objfile for a given address.
37940 While on some ports like on AMD GPU we have thread-specific address
37941 spaces, and so when accessing memory for those address spaces, we must
37944 API as is can't be used to access thread-specific address spaces.
37945 IOW, it can only be used to access the global address space that is
38656 effectively returning two levels of the call stack. Neat (I guess).
39285 symbol. We could align by setting the address of the section (by
39291 Set address to zero when not a final link.
39646 address in the test name:
39654 If for whatever reason the stack address changes between test runs
39658 stack address:
40081 HS6x supports 64-bit virtual and 52-bit physical address spaces to
40102 - Use the FSF postal address rather than their URL.
40131 Cannot access memory at address 0xfff80001002011e0
40132 Cannot access memory at address 0xfff80001002011d8
40133 Cannot access memory at address 0xfff80001002011d8
40143 address we're accessing has its high bit set. See
40687 This change was rejected by the kernel team, the current
40734 today. I plan to try and address this in a later commit, however,
40880 opcodes/loongarch: Mark address offset operands of LVZ/LBT insns as such
41651 opcodes/loongarch: style disassembled address offsets as such
41653 using the address offset style, and mark the memory access instructions'
41658 * loongarch-dis.c (dis_one_arg): Style disassembled address
41660 * loongarch-opc.c: Add 'o' to operands that represent address
42580 Sync config.guess and config.sub with upstream master versions.
43924 says that "The size of the data retrieved from the dereferenced address
43925 is the size of an address on the target machine."
43927 On x86_64, the size of an int is 4 while the size of an address is 8.
44655 …==80377==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000068034 at pc 0x564785cba…
44828 the process's address space.
44844 same file was mapped multiple times in the process's address space, the
45194 address is compared to an unrelocated address.
45267 This commit aims to address PR gdb/21699. There have now been a
45998 Added new load address pseudo instruction which is always expanded to GOT
46322 which ends up trying to push the string into the inferior's address
47383 to address that - refactor the function and use better names to make it
48103 subtracted in the prologue. Clang fails because the return address that
48113 x86/Intel: address quoted-symbol related FIXMEs
48114 If in a "word ptr <address>" or alike construct the "ptr" part is
48291 The fix for pr23686 had a hole in the reloc address sanity check,
48297 r->address sanity check.
48448 GDB's symtab_and_line lookup, we try to find a result for an address,
48491 an invalid address.
48502 returns an unexpected address at some point during the test.
48532 3. And I have included the address of the bp_location in the warning
48642 x86: further adjust extend-to-32bit-address conditions
48643 While a442cac5084e ("ix86: wrap constants") helped address a number of
48691 x86: tighten extend-to-32bit-address conditions
48791 with the actual address of IFUNC symbol, it will call the IFUNC resolver
48792 function and take the return address, uses it as the sym-bound address
48793 and puts it in the .got.plt entry. Initial address in .got.plt entry is
48796 a .plt entry address to fill in the corresponding .got.plt entry.
48799 IFUNC function addresss. First check to see if the real address for
48814 .got.plt entry and determines if the contents is the correct address
48816 principle analysis above, the address filled in the .got.plt entry is
48817 not the actual target function address initially, it would be a .plt
48818 entry address corresponding symbol like *@plt. In this case, gdb just
48819 go back to execute the resolver function and puts the return address
48820 in the .got.plt entry. After that, gdb can get a real ifun address via
48823 On LoongArch, initially, each address filled in the .got.plt entries
48824 is the first .plt entry address. Some architectures such as LoongArch
49251 text part or address part and store these parts in a vector.
49260 address be printed, and takes care of printing the address and
49294 address which the part represents, but in order to support backwards
49380 If a function symbol only get its address by la.global, without
49663 the "generic type" has the size of an address on the target machine, which for
50139 * testsuite/ld-scripts/map-address.exp: Run the new test.
50313 …==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7…
50655 protection I guess we'd need to run all gdb.python/*.exp tests with
50767 indexer picks up an address for this symbol:
50780 1. Find a constant address of a symbol that happens to be encoded as a
51105 …gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in …
51261 …xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_…
51321 I guess, as the source file has the '.cc' extension, all the compilers
51849 4 bytes of memory at address 0x00007fffffffdc5c changed from: 6a 01 00 00
51866 4 bytes of memory at address 0x00007fffffffdc5c changed from: 00 00 00 00
51877 4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00
52215 It felt like this would be an easy issue to address by adding a
53297 opcodes/i386-dis.c:9865:22: error: storing the address of local
53348 For quite come time print_insn() has been storing the address of a local
53724 an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr
53725 to convert from a function descriptor to the address recorded at the
54064 e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT&T
54162 The instruciton didn't have the same address with mapping symbol will
54166 1) Use the last mapping symbol status if the address is still within the range
54308 inferior has vforked. We are already attached to the parent's address
54317 amd-dbgapi needs to be aware of the new address space created by the
54744 gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.exp
54761 On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
54764 gdb.base/dump.exp has the following code to check 64-bit address
54767 # Check the address of a variable. If it is bigger than 32-bit,
54793 The variable address difference here is due to the link script
54813 Because 64-bit variable address out of range for IHEX, it's not an
55253 * symtab.c (symtab_finalize): Only change the end address if dst has been updated.
55673 that included a stack address in the test name, this makes it harder
55677 address.
55680 writing 8-bytes rather than 4 in order to clear the return address
55901 This commit aims to address a problem that exists with the current
55962 report), the signal stops the inferior at the address of the displaced
55982 This commit only aims to address the issue on amd64 for now, though I
56234 under bfd/po/, i.e. in maintainer mode.
56582 located anymore, is not great. I'll address that in the next commit.
56631 Cannot access memory at address 0x0
56703 Cannot access memory at address 0x0
56763 When we are at address 0x101a4 the previous instruction has restored
56765 frame-pointer as the frame base address is clearly not going to work.
56768 At address 0x101a6 the previous instruction has restored the
56819 This change started as a wider fix that would address all the failures
57125 the return address (that is in fact an orthogonal GDB bug). I expect it
59022 We do print out the address that is being stepped, so I can track down
59402 gcc-13 -fsanitize=address,undefined complains about this, but not
59405 to address 0x62600000016c with insufficient space for an object of
60297 enabled more broad use of pointer authentication masks to remove non-address
60366 using a default mask to remove non-address bits of a pointer.
60375 to remove the non-address bits should be enough.
60378 to access a memory address (now that gdb is capable of reading memory even
60379 with threads running). Thus gdb will attempt to remove non-address bits
60656 FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated
60703 These tests run "maintenance info line-table" to record the address of
60804 x86/gas: support quoted address scale factor in AT&T syntax
60888 Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1".
61026 The first question to address is why we are calling a C++ support
61240 commit doesn't address the issue in the C++ code which was fixed with
61463 Regen ld/po/BLD-POTFILES.in
61719 and now it's not possible to compare an unrelocated address from a
61794 using target_ops::insert_watchpoint. For all these, the address is
61796 address. bp_loc_other is a catch-all for "the rest", in practice for
61797 catchpoints that don't have a specific address (hence why
61800 that specific signal. GDB doesn't associate an address to that.
61802 But tracepoints do have a meaningful address to thems, so they can't be
61844 This patch adds a new address to struct execution_control_state to hold the
61845 address of the alternate entry point (GEP). The finish_backwards function
62366 noalloc section types. That also allows the address of .comment to be
62373 * scripttempl/misc-sections.sc: Set .comment address to zero
63821 gas: allow frag address wrapping in absolute section
63829 I think we can allow the address wrap.
63831 * frags.c (frag_new): Allow address wrap in absolute section.
64139 Use size_t variables. Sanity check reloc address. Handle
64144 * coff-z80.c (extra_case): Sanity check reloc address. Return
65288 Fix typo with my email address
66807 patch) was unknown. I guess it ends up working because there is a `c`
67937 stabs_end - STABSIZE is then a pointer to a very large address, the
68127 2 - The hook to remove non-address bits from a pointer needs to be registered
68166 Backtrace stopped: Cannot access memory at address 0xffff80000a96c0c8
68826 inferior, and the current address space (like proc-service.c).
68912 Taking a step back, the -nostartfiles -static was added to address that the
69540 …==1527735==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210003392a8 at pc 0x55e4c26e…
70965 address that request, but it is probably worth reading that PR when
71751 warning: Breakpoint address adjusted from 0x83dc305fef755015 to \
71755 Cannot access memory at address 0xffdc305fef755015
72301 - Add stack and code address parameters to create_sentinel_frame, to be
72580 offset to the address. It seems to me that the choice of offset here
72587 applying it to a symbol when the address is set. This is done for
72932 file as I guess it is possible that some people might hit this new
73028 start address alignment. This would avoid penalizing the ARM32 hosts,
73532 svr4 probe is that the stop address, and only call
74164 And finally the address map contents:
74175 The display of address maps above could probably be improved, to show it
75185 …d": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 4…
75194 the new breakpoint address, and recording the address from there. I
75200 - Get the address by doing a breakpoint insertion after the program is
75202 - Do the disassembly by symbol instead of by address.
75430 silently because a compilation fails. I didn't attempt to address
75985 [gdb/tdep, aarch64] Fix frame address of last insn
76062 The frame address is calculated here in aarch64_make_prologue_cache_1:
76249 …#0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/…
76253 …#0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/…
76349 I don't want to address all the `select-frame view` issues , but I think
77104 data + reloc_entry->address. This patch adds the missing checks and
77339 This patch adds a new address to struct execution_control_state to hold the
77340 address of the alternate function start address, known as the GEP on
77349 Note, on systems that only support one entry point, the address of the two
79298 * po/SRC-POTFILES.in: Regenerate.
79485 FDEs will be sorted in the order of their start address. So, remove
80039 4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00
80150 here, if the argument is already in memory, that address will simply
80286 should address this problem, but this patch is a simpler fix which is easy to
80752 left main, at which point I guess we don't stop till thread exit.
80782 return address at which the breakpoint is set, is also the first instruction
80873 address due to inlining.
81229 libsframe: write out SFrame FRE start address correctly
81233 The offending stub was how we memcpy the FRE start address to the buffer
81234 (on-disk format). When the host is big-endian, the address of the
81767 address type.
81774 The latter type matches the address size configured for this sim.
81782 The latter type matches the address size configured for this sim.
81788 the upper 32-bit address range in 64-bit sims is inaccessible. Use
81802 Since SIM_ADDR is always 32-bit, it might truncate the address with
82445 Regen opcodes/po/POTFILES.in
82457 The core device has an attach address method as the root of the tree
82467 the sim core API to detach from the address space.
82570 (display_debug_addr): Fail if the computed address size is too big
82790 address is a signed (mangled) one.
82847 encountered, it means the upper bits of the return address contain Pointer
82955 address of the label into a value object with builtin_core_addr type.
82961 Now it's not clear what type a goto label address should have, but
82962 GCC has an extension that allows users to take the address of a goto
83052 [aarch64] Fix removal of non-address bits for PAuth
83056 non-address bits from pointers, and it is specified by a constant. This
83057 constant represents the number of address bits in a pointer.
83063 from the address space to store the required information. We could also have
83068 of the non-address bits.
83076 bits. The hook is now responsible for removing the required non-address bits
83077 and sign-extending the address if needed.
83080 new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.
83180 - #2. access to the SFrame FRE start address in the on-disk representation
83409 print an assert during exit, but to address the root cause of the
84372 x86-64: allow HLE store of accumulator to absolute 32-bit address
84374 absolute address") I was wrong to exclude 64-bit code. Dropping the
84443 part of that change wasn't even necessary to address PR gas/29844.
84567 $1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M
84584 $1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>
84621 /* Recompute output address in R1. */
84670 - 1-bit: FRE start address encoding
84674 address encoding of SFRAME_FDE_TYPE_PCINC has a value of zero, and the upper
84700 range of offsets that can be encoded in the start address of an SFrame
84701 FRE. E.g., sframe_frame_row_entry_addr1 is used when start address
84800 address using _bfd_mips_reloc_offset_in_range.
84805 (gprel32_with_gp): Check reloc address using
84812 (_bfd_mips_elf_gprel16_with_gp): Move reloc address checks to
84814 (_bfd_mips_elf_lo16_reloc): Check reloc address using
84816 (_bfd_mips_elf_generic_reloc): Check reloc address using
84818 (mips_elf_calculate_relocation): Check reloc address before calling
84821 (mips_elf_read_rel_addend): Add sec param, check reloc address
84833 (gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address
84847 File name Line number Starting address View Stmt
84996 have BFD but that's not always true. To address this problem, this
85513 gdb: Update my email address in MAINTAINERS
85930 * po/POTFILES.in: Likewise.
86002 (verilog_write_section): Adjust the address by the data width.
86506 configuration and return an address of an exported object from it.
86526 address of global xtensa_modules.
86963 …#23 0x00000000008995a5 in ext_lang_print_insn (gdbarch=0x5335560, address=0x401195, info=0x7fff9ab…
87078 But, whatever the ultimate decision from the glibc team, given there
87183 address of the breakpoint is shown.
87185 The problem is that test-case doesn't expect the breakpoint address.
87187 Fix this by allowing the breakpoint address to occur.
87383 …_db_thread_handle (ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa…
87385 … <the_x86_target>, ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa…
87470 File name Line number Starting address View Stmt
88167 execution to verify that the catchpoints are indeed not hit. I guess
88356 gdb/linux-tdep.c), so address that by adding comments where those are missing.
88389 minimal symbol instead of an address as argument
88568 opcodes: Correct address for ARC's "isa_config" aux reg
88569 This patch changes the address for "isa_config" auxiliary register
88575 * arc-regs.h: Change isa_config address to 0xc1.
88995 Currently, FinishBreakpoints are set at the return address of a frame based on
89059 GDB. This should fail because GDB can't take the address of the in
89170 # and end address too:
89248 be sent straight to the assembler. My guess is that Clang doesn't
89365 determine the address off the return buffer when the function is called.
89517 are stored as an address and length, it is fine to include an embedded
89550 /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address
89934 The linker sorts the SFrame FDEs on start address by default and sets
90203 specific fragments containing SFrame FRE start address and SFrame FDE
90696 ABI uses register r3 to store the address of the buffer containing the
90710 return buffer address, in the case of a function returning a nontrivial
90716 On PowerPC, the new gdbarch method will return a nonzero address in
90718 return buffer address to get the return value.
90731 This patch address five testcase failures in gdb.cp/non-trivial-retval.exp.
90761 the address of the buffer containing the function return value in register
90764 the return buffer address cannot be reliably obtained from register r3.
90887 This commit tries to address this issue on the GDB side. We have
91058 Instead, simulator must obtain the loop's end address directly from
91248 The way it is now, we first write the address of the displaced step buffer
91578 (%dx) isn't a valid memory address in any modes. It is used as a special
91579 memory operand for input/output port address in AT&T syntax and should
93008 "End of assembler dump" to determing the last address in the function. The
93442 it has the same address as $d. Therefore, we will get the unexpected result
93456 when it has the same address of $d. Try to add the removed $x+arch back
93757 that '%a' might print an address for one *_opcodes table, but in a
93944 routine tries to setup the three hardware watchpoint address since the hw
93969 are watched. The val_chain contains the address for **global_ptr_ptr and 0
93974 loc 0: b->address = 0x100009c0
93976 loc 1: b->address = 0x7ffff7f838a0
93978 loc 2: b->address = 0x7ffff7b7fc54
93980 loc 3: b->address = 0x7ffff7a5788c
93982 loc 4: b->address = 0x0 <-- location pointed to by global_ptr_ptr
93983 loc 5: b->address = 0x100200b8 <-- global_ptr_ptr watchpoint
93985 loc 6: b->address = 0x7ffff7b7fc54
93990 breakpoint consist of the address for global_ptr_prt, global_ptr and buf.
93994 loc 0: b->address = 0x100009c0
93996 loc 1: b->address = 0x7ffff7f838a0
93998 loc 2: b->address = 0x7ffff7b7fc54
94000 loc 3: b->address = 0x7ffff7a5788c
94002 loc 4: b->address = 0x10020050 buf
94003 loc 5: b->address = 0x100200b0 watch *global_ptr
94004 loc 6: b->address = 0x100200b8 watch **global_ptr_ptr
94006 loc 7: b->address = 0x7ffff7b7fc54
94014 call to setup each of the three address for breakpoint 4. The slot
94078 5039 | as_warn (_("only support RIP-relative address"), i.tm.name);
94726 [gdb/testsuite] Remove address from test names
94727 I noticed an address in a test name:
94733 Stabilize the test name by using "set breakpoint on address" instead.
95189 bfd_reloc address against subsection size.
95194 Fuzzed object files can put random values in bfd_reloc->address,
95276 same changes to the gdb_test_multiple that consumes the stack address,
95887 * po/hu.po: Updated Hungarian translation.
96306 Regen ld/po/BLD-POTFILES.in
96477 symbol address for addr2line test. Handle default executable
96814 to handle copy relocations but it now causes a wrong address to be
96925 This implementation uses the address of a namespace's r_debug object as
96937 executable. The load map address of this main executable is provided in
96974 namespace's r_debug address to identify the namespace.
97050 should match the address at which the breakpoint was set in the dummy
97118 Since "NULL" and "0" are used to represent invalid address in function
97340 Setting SP of the next frame to the same address as the current frame
98312 Memory tag violation while accessing address 0x0000ffff8ef5e000
98961 gdb: include the base address in in-memory bfd filenames
98967 and, at the same time, adds the base address of the symfile into the
98975 replaced with the base address for where the in-memory symbol file was
98982 jit_code_entry address symfile address symfile size
99569 make[4]: Entering directory '/home/alan/build/gas/all/bfd/po'
99570 …to make target '../elf32-aarch64.c', needed by '/home/alan/src/binutils-gdb/bfd/po/bfd.pot'. Stop.
99577 x86/gas: support quoted address scale factor in AT&T syntax
100490 etc. This commit doesn't attempt to address these cases as non of
100619 commit will address the other issue.
100908 first byte is from the lowest address, and subsequent bytes are from
100981 which is undefined when combined with passing an address of the accessed
101617 $1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.
102740 Making info in po
102741 make[3]: Entering directory '/build/gas/all/bfd/po'
102742 cd .. && make po/SRC-POTFILES.in
102743 cd .. && make po/BLD-POTFILES.in
102763 * Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES).
102764 (po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES).
102962 if the DWARF address matches the symbol address, and if the symbol
103403 address 0x400608 starts at a line entry:
103406 File name Line number Starting address View Stmt
103411 and therefore the breakpoint is printed without instruction address.
103414 address:
103427 address 0x004004c1 doesn't start at a line entry:
103430 File name Line number Starting address View Stmt
103438 for the address compdir_missing__ldir_missing__file_basename_label, making
103440 - expecting the breakpoint to be printed without instruction address.
103482 Not that anyone would want to indirect via the GOT when an address can
103997 address. This test was changed to actually measure address changes,
104166 size is 27, from "64-bit address is disabled").
104413 past the prologue, to address 0x4022f7:
104428 File name Line number Starting address View Stmt
104494 Process record does not support instruction 0x7f70ee1d at address 0x0.
104884 RISC-V: Print highest address (-1) on the disassembler
104885 This patch makes possible to print the highest address (-1) and the addresses
104887 address space is used for I/O registers and corresponding symbols are defined.
104888 Besides, despite that it is very rare to have GP the highest address, it would
104889 be nice because we enabled highest address printing on regular cases.
104894 address (-1) printing.
104898 GP-relative addressing when GP is the highest address (-1).
104905 enable printing the highest address.
104911 RISC-V: PR29342, Fix RV32 disassembler address computation
104913 incorrectly sign-extended address is produced when printing. This commit
104914 fixes this by fitting an address into a 32-bit value on RV32.
104916 Besides, H. Peter Anvin discovered that we have wrong address computation
104922 * testsuite/gas/riscv/lla32.d: Reflect RV32 address computation fix.
104928 * riscv-dis.c (maybe_print_address): Fit address into 32-bit on RV32.
104929 (print_insn_args): Fix JALR address by adding EXTRACT_ITYPE_IMM.
104933 RISC-V: Add address printer tests with ADDIW
104941 * testsuite/gas/riscv/dis-addr-addiw.s: New to test the address
104958 sim: Update mailing list address
104960 back in 2009 changed the mailing list address gdb-patches@sources.redhat.com
104967 * MAINTAINERS: Update mailing list address.
105332 A later patch in this series will address this issue, and will remove
105864 round the address down.
106014 On x86, the PLT entry in executable may be used as function address for
106016 address used in executable can be different from the function address
106026 in executable as function address is safe since function pointer equality
106083 (target at odd address), or an overflow.
106220 binutils: Updated my email address.
106222 * MAINTAINERS (RISC-V): Updated my email address.
106542 a couple instructions and leaves us in a nice spot where the address to the
106707 getting close to address wrap-around.
106949 broke i386-gen's emitting of diagnostics. As a replacement to address
107156 File name Line number Starting address View Stmt
107161 the address does not fall at an actual line, so the breakpoint is shown with
107162 address, both when setting it and hitting it.
107239 unrelocated address (the objfile's text_section_offset () is 0). As a
107241 address, so cannot evaluate the value of the global. Note that the
107243 can be created. When using a non PIE executable, the address of the
107557 start address 0x0000000000000000
107842 …time ./objdump --start-address=0x0000000004e0dcd0 --stop-address=0x0000000004e0df8b -l -d --no-sho…
108960 register at the lowest address [2].
109918 address of a section rather than at the insn of interest. Undo part of
109926 for such arises, quite likely the only way to address this would be to
110193 address: installed address of the location
110284 Cannot access memory at address 0x40fdd5
110554 address sanitizer build, this leads to a plain error. For non address
111111 Re: PowerPC64 .branch_lt address
111120 out at a higher address. That's due to the address expression for
111131 .branch_lt address to take into account possible user sections
111298 We can't use the PLT entry as the function address for PIC since the PIC
111460 address function does some combination of reading the symbol table, or
111553 (gdb) show mips mask-address
111555 The 32 bit address mask is set automatically. Currently disabled
111558 The 'show mips mask-address' command ends up in show_mask_address in
111590 (gdb) show mips mask-address
111600 (gdb) show mips mask-address
112136 address of foo, the pointer equality will break, but the error should be
112144 address taken operation in the executable doesn't work with protected
112480 Tested on x86_64-linux, by building with -fsanitize=address and running
112662 correctly locating the address of the bclr instruction before the statement
113140 When building gdb with -fsanitize=address we run into:
113556 The -msign-return-address switch has been dropped from GCC, but some
113558 -msign-return-address and -mbranch-protection before bailing out when
113601 The disassembler also makes use of the 'address' and 'function'
113605 set/show style disassembler address
113610 set/show style address
113614 disassembler related style settings. The 'address' style is used to
114200 This does not break anything. The variable was merely used to address a
114837 those aren't easy to address without re-flowing almost the entire
115044 considered zero-extended) displacements is when an address size override
115372 …==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa30…
116220 Fix gdbserver build with -fsanitize=address").
116265 Note that I didn't touch */po/*.po{,t} on the assumption that these
116270 Fix location list offset address dump under DW_AT_location (dwarf-5)
116271 For clang compiled objects with dwarf-5, location list offset address dump
116273 dumping the location list offset, the address dumped is wrong where it was
116283 PowerPC64 .branch_lt address
116294 * emulparams/elf64ppc.sh: Set .branch_lt address fixed relative
116373 <183> DW_AT_name : address
116568 If your core_pattern is just "core" (but why??), then I guess that you
116807 address of foo (likely due to -fno-pic), the pointer equality will
117155 (display_debug_ranges): Add rnglists_base to the .debug_rnglists base address.
117456 an address location), and for actual resolved locations, like the
117518 FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
117776 properties: address, architecture, and progspace. And has methods:
118171 accidentally hit a valid address, but with target board unix/-m32 that's not
118234 example, despite the FIXME I'd guess leaving out the EI_VERSION check
118709 get_compiler_info, I guess maybe the original thinking was that if a
118776 [4] system.traceback.symbolic.value (system.address) return string at \
119224 When looking for how to apply styling I guess the ideal solution would
119279 I don't think it is, we don't actually print address and symbol
119281 back to the user (objdump, gdb, etc) to print the address and symbol
119352 I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.
119583 Update my email address in gdb/MAINTAINERS
120088 Self test failed: Cannot access memory at address 0x0
120131 Self test failed: Cannot access memory at address 0x0^M
120361 branch instruction and determine the address of the next instruction on
120696 defined symbols residing at the address of the pointer. For the given
121365 "linespecs", "explicit location", and "address location" input
121369 locations in the program that correspond to the address/file/lineno of
121417 accepts a "location", suggesting it can accept address and explicit
121422 "line specification", but it can accept address and explicit
122209 that the address space is gone and the whole process has exited or
122763 from the base address. This was however incompatible with
122765 to the base address. Ada's convention has therefore been
123051 location to decide whether the location has a meaninful address to
123057 document for bp_location::address:
123061 CORE_ADDR address = 0;
123344 In aix-thread.c we use ms->value_address () to get the symbol address.
123355 add a trie to map quickly from address range to compilation unit
123360 475k address ranges, which takes a long time when done repeatedly.
123362 Add a radix-256 trie over the address space to quickly map address to
123365 0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x
123628 Prior to trying to address PR gas/28888 I noticed anomalies in how
123680 for the return address from the link register.
124431 test-case uses 'main_label' as the address of the first and only valid entry
125740 0x<hex address> <test_signal_handler>: endbr64
125742 On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
125746 0x<hex address> <__kernel_start_sigtramp_rt64>: bctrl
125834 Consequently, the address for foo determined by get_func_info doesn't match
125835 the actual address of foo.
125837 Fix this by printing the address of foo using the result of gdb_compile_shlib.
126195 ... where 0x7ffff7d7ac5a is the exact address of the vfork syscall
126432 Cannot access memory at address 0x555555558010
128486 The value RIGHT is needed to force the address of the library functions
128487 lib1_func3 and lib2_func4 to occur at different address in the wrong and
128581 code sections are. My guess is by default PowerPC allocates a larger
128589 data section forces the code section to a different address. That was
128595 good backtrace because the address of lib1_func3 and lib2_func4 both
129095 function prologue from START_PC to LIMIT_PC, return the address of
129643 to the target at the specified address. (...) */
129689 .debug_aranges that has both address and length of 0. In this
130141 forever, but the "if" is still there, so I guess the "if" can stay
130278 this makes a small change to have write_address_map accept the address
130558 have address information, so that the new indexer will know to do
130785 #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0)
131414 Cannot access memory at address 0x113b^M
131418 The test loads the binary in GDB, grabs the address of a symbol, strips
131420 a breakpoint at that address. The problem is that the binary is built
131421 as position independent, so the address GDB grabs in the first place
131425 alternative would be to compute the relocated address where to place the
131429 manually to get the symbol address, but GDB was telling me the symbol
132379 return the address, rather than a string.
132408 in a separate register, thus we don't need to mask/unmask the return address
132415 return address signing/authentication instructions.
132427 the return address.
132556 Note the lack of hexadecimal address in the failing case. Whether or
132557 not the hexadecimal address is printed (roughly) depends on whether the
132838 breakpoints inserted in the shared parent/child address space, in case
132844 is, when the child has exited or execed): since the address space is
132849 2. Remove breakpoints from the (shared) address space and set
133062 foo's first address past the prologue.
133103 0xa94c, 0xa800 is the address at which the breakpoint should be placed
133113 guess it.
133583 objdump_print_addr_with_sym, where we print an address and a symbol
133788 address (what the top of addr_stack represents), and the case where
133789 the DWARF expression does require the address.
133799 and using this to decide if we should push the object address or not,
133805 address from the addr_stack as an item in the array view.
134564 Regen bfd po/SRC-POTFILES.in
134640 This core dump note contains the value of the base address of the %fs
134642 useful in resolving the address of TLS variables in core dumps.
134904 …tils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebeb…
135348 can either), it seems safest to address this before checking in the
135772 gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp
135773 The test gdb.python/py-format-address.exp, added in commit:
135780 included 3 copy & paste errors where the wrong address was used in the
135787 We then take the address of the name changing function in both
135797 compiler, and that 'foo' and 'bar' will be at the same address. This
135802 never is. If the executables are compiled as PIE, then the address in
135803 the inferior 2 will not have been resolved, while the address in the
135811 The first part of the fix is to use the correct address variable in
135816 compile the tests, this should ensure that the address obtained in
135817 inferior 2 is the same as the address from inferior 1, which makes the
135830 Changes were made to GDB to address some inconsistencies in when
135866 here a 2nd time for the same "addr". And indeed passing the same address
135997 spot using call_site_target::address now passes in a callback function
136207 At this occasion also update my email address in the pre-existing, much
136216 gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp
136231 The second of these commits was intended to address periodic test
136588 stored in the 64-bit field being relocated. But I guess it would be a
136731 register holding the address for a breakpoint hit must be fetched in a
136820 This method takes an address, and returns a string with the format:
136824 Where, ADDRESS is the original address, formatted as hexadecimal,
136825 SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is
136841 inferiors program space, and address is formatted using the
136847 In order to format an address for a different inferior.
137064 (gdb) break *0x00007ffff729e2f1 # Use address of probe.
137486 of line sets address.
137920 * po/SRC-POTFILES.in: Regenerate.
138089 The result of that thread was that readline was patched to address
138290 To address this problem, we have to move notification logic up to
139480 #1 - My first thought to address the race was to make GDB always
140464 Update my e-mail address in the MAINTAINERS file
140541 architecture. The vDSO is mapped at the address given by the
141267 ".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"
141334 Mapped address spaces:
141355 Mapped address spaces:
141376 Mapped address spaces:
141458 * Changed debug CSR address of scontext from 0x7aa to 0x5a8. We cannot support
142549 already memory allocated at that address.
142642 disassembler output, and, I guess, how pygments is configured.
142647 Currently, when the disassembler wants to print an address, we call
142648 back into GDB, and GDB prints the address value using the `address`
142651 through pygments, and this include the address and symbol name parts
142662 unstyled, but the address and symbols are styled using the `address`
142765 address 0x10000 and data at 0x20000 for a total of two 64k memory
142806 fixed address mod MAXPAGESIZE. So for relro the linker can't play
142958 The problem is that when we reach address 0x108 and use 'until',
142971 loops back to address 0x104.
142974 the new address is marked as a statement, and that the new address is
142988 0x114, the first address associated with a different line.
142992 range, and the stepping finishes at address 0x114.
143007 the jit_code_entry address, but also the symfile address, and the
143016 Additionally, the symfile address is the same address that is now used
144462 This commit includes the JIT object's symfile address in the names of
144467 The address is the one that the debugged program has put in
144478 alias for a CORE_ADDR) that includes the address of the code entry in
144479 the inferior's address space (the previous meaning of
144481 GDB's address space. And while at it, pass down the gdbarch, so that we
145297 FreeBSD x86: Remove fallback for detecting signal trampolines by address.
145479 …==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b23…
145601 #2 0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
145638 a relocated address. For some ABIs, such as the System V ABI, the
145645 In stap_probe::get_relocated_address, the address to which to add the
145646 offset (thus forming the relocated address) is obtained via
145650 /* The address where the probe is inserted, relative to
146072 the destination address, it is actually copying into the first member
146252 The address part of the command might change between execution of the
147067 Update the config.guess and config.sub files from the master repository and regenerate files.
147195 meantime. Note that this also happens to address the prior lack of
147718 "lappend expected "ptid: \\($process_id, $process_id, 0\\)" "address: $addr""
148046 In a later commit I want to address an issue with the Python pygments
148803 DUPLICATE: gdb.base/shlib-call.exp: set print address off
149210 * po/fr.po: Same.
149211 * po/ru.po: Same.
149212 * po/uk.po: Same.
149229 * po/fr.po: Same.
149230 * po/ru.po: Same.
149231 * po/uk.po: Same.
149900 fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
150355 out */po/*.pot which we don't update frequently.
150697 the address of a member and then passing this (as a void*) to these
150925 - Hypervisor CSRs (some new, some address changed)
151012 there is no thread-id and so has to "guess" which thread the stop
151055 remote_debug_printf ("is this guess ambiguous? = %d", ambiguous);
151147 allocated for it by the caller, and the address of this space is
151149 then return the address of this space as the return value.
151152 A, actually contains the address of an instance of A (in this case on
152259 PRs before as wontfix, but I guess there will be no end of this type
152263 an error string instead. The address of the string varies with PIE
152264 runs and/or compiler, and we allow that address to appear in output.
152402 versions too), -O2 and -fsanitize=address, I get this error.
152439 …ree=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address -c -o tracepoin…
152541 * code-model-01.ld: the text section is in the 32-bit address range, but
152543 section is over the 32-bit address range.
152545 * code-model-02.ld: the text section is over the 32-bit address range, but
152546 the data section is placed nearly zero address.
152651 My guess is that this approach allows us to handle indexing off the
152864 My guess is that leaving mips_nbsd_nat_target unchanged was an
153636 _("64-bit address is disabled"));
153676 0x0000000000000000: 64-bit address is disabled
153697 0x00000000: Cannot access memory at address 0x0
153704 Cannot access memory at address 0x0
153822 kernel's PRNG has reseeded. AT_KPRELOAD is the base address of a
153911 Line 20 of "tui-layout.c" starts at address 0x4004a7 <main> \
153917 Line 21 of "tui-layout.c" starts at address 0x4005f4 <main> \
153957 where the first insn at 0x8048310 initially jumps to the following address
153983 where the insn at 0x3f0 initially jumps to following address 0x3f6, read from
154171 address, and it's only 16-byte aligned:
154177 Fix this by using a sufficiently aligned address, using _Alignas.
154511 To address this, add a `copy` free function that copies data from an
154655 which, when run with the address sanitizer enabled, highlights the
154665 The gdb.server/server-connect.exp now runs cleanly with the address
155883 Cannot access memory at address 0x0
155895 _("64-bit address is disabled"));
155906 value happened to be in the memory error address variable, the default
155913 Cannot access memory at address 0x0
155936 disassemble at address 0x100, this should avoid us being able to pass
155937 by printing a default address of 0x0. I did originally change the
155938 address we disassembled at to 0x4, however, some architectures,
155941 an address, but I figured that 0x100 was likely to satisfy most
156381 To address this limitation, create a suite of FOR_TARGET variables
156915 however, since A::e does not demand an unique address, it gets the same
156916 address (and thus byte offset) of the members, making A::e and B::e have the
156917 same address. however, "print c.e" would fail to report the ambiguity,
156963 * po/BLD-POTFILES.in: Regenerate.
156964 * po/SRC-POTFILES.in: Regenerate.
156969 * po/fr.po; Updated French translation.
157368 Update bug reporting address
157373 * po/Make-in (msgid-bugs-address): Likewise.
157377 * po/Make-in (msgid-bugs-address): Update.
157379 * README: Update bug address. Delete mention of gcc.
157380 * po/Make-in: Update bug address.
157382 * po/Make-in: Update bug address.
157384 * po/Make-in: Update bug address.
157386 * po/Make-in: Update bug address.
157388 * po/Make-in: Update bug address.
157942 It would be nice if the assembler could handle this somehow. But I guess
158334 the given address. For example, 'x/-3uh 0x54320' prints three halfwords (h)
159117 for the address of 'mnimonic' will never be NULL [-Werror=address]
159410 a new Entropy Source CSR define 'seed' located at address 0x015.
159422 Also defined new csr seed, which address is 0x15.
159535 Update my email address.
159538 work. My tuliptree address still works, it just isn't as convenient.
159541 * MAINTAINERS (RISC-V): Update my address.
159830 …ocation.c:963:38: error: the address of 'event_location::<unnamed union>::explicit_loc' will never…
159837 GCC is right, EL_EXPLICIT is defined as returning the address of an
159976 * po/POTFILESin: Regenerate.
160141 The c.nop at address 0x6 is generated for alignment, but since the rvc isn't
160240 since the environment requires code to based at address 0. We can
160763 DWARF 5 work), it was written to add the base address. However, this
160764 seems incorrect -- the DWARF standard describes this as an address,
160765 not an offset from the base address.
161294 "0" out of read/write is normally what you get when the address space
161310 but the thread exits just after and clears its address space pointer.
161312 ends up with no address space associated, so a subsequent read/write
161329 post-exec address space thinking we're accessing the pre-exec address
161393 the pointer address varies.
161708 supports the tagged address ABI but not MTE (PR 28355).
161721 Currently for a binary compiled normally (without -fsanitize=address) but with
161912 gdb/sim: update my email address
161915 * MAINTAINERS (Global Maintainers): Update my address.
161921 * MAINTAINERS (Global Maintainers): Update my address.
162390 PR28518: signed integer overflow & free on unmalloced address
162392 * vms-alpha.c (build_module_list): Don't lose malloc buffer address.
162617 arch with a 64-bit address size when bfd_vma is 32-bit.
162999 ASSERT in empty output section with address
163002 * testsuite/ld-scripts/empty-address-4.d,
163003 * testsuite/ld-scripts/empty-address-4.s,
163004 * testsuite/ld-scripts/empty-address-4.t: New test.
163005 * testsuite/ld-scripts/empty-address.exp: Run it.
163061 The test-case only uses the v4 address 127.0.0.1, so fix this by:
163538 * po/BLD-POTFILES.in: Regenerate.
163576 * po/POTFILES.in: Regenerate.
163634 * po/POTFILES.in: Regenerate.
163659 * po/BLD-POTFILES.in: Regenerate.
163660 * po/SRC-POTFILES.in: Regenerate.
163912 address attached to the pcrel_lo.
164154 …ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_he…
164168 …ledata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
164326 particular field being resolved. While it offsets the address here,
164506 We can't get at section->address() until everything is laid out, so
164623 [gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31.
164626 rather than the calculated effective address (ea) by the
164638 The problem here is that the address used in the memory_error call is
164670 0x000101aa <+0>: Cannot access memory at address 0x0
164982 address that was a problem.
164984 Without this GDB will report all memory errors as being at address
164997 address that was a problem.
164999 Without this GDB will report all memory errors as being at address
166001 have an empty address range, due to using asm labels in global scope,
166317 It can be difficult to guess the exact bfd name, so add an option to
167237 while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\."
167390 So I guess I'm running into the same problem for x86_64.
167677 Since add_location_to_breakpoint uses only the address as a criterion to
167678 sort locations, the order of locations at the same address is not
167751 There's not many places where we call internal_warning, and I guess in
168075 their program space and address space. To reproduce:
168090 share one program space and one address space:
168729 Line 0: address 0x7fffffffd4c0 [47 hits]^M
168730 Line 1: address 0x7fffffffd500 [31 hits]^M
168731 Line 2: address 0x7fffffffd5c0 [7 hits]^M
169348 However, the backtrace only shows an address, because:
169355 fix this by doing info probes and grepping for the address.
169381 However, the backtrace only shows an address, because:
169491 address, and the presence of the "caller of frame at" info. All the
169509 used as an address again.
169520 The ptid_t 'tid' member is normally used as an address in gdb -- both
169632 try the start address of the entry section when creating an
169636 testsuite/ld-alpha/tlspic.rd: Update expected entry point address.
170423 The problem is that the CU and function both have an empty address range:
170435 The address ranges are set like this in dw2-abs-hi-pc-hello-dbg.S:
170572 However, the address map of the partial symtabs incorrectly maps addresses
170575 The address map of the full symbol table of the foo CU however does not
170920 #x <address> in <fn> ...
171340 but we can address that in a follow up commit. This mirrors what
172246 1) If you use "-fsanitize=address,undefined" in CFLAGS, the Makefile
172374 * po/BLD-POTFILES.in: Regenerate.
172760 0x0000000000000000: Cannot access memory at address 0x0
173144 even if they have no address range.
173303 address ranges, and a function without debug info whose address is
173575 Fixes a silly mistake in calculating the address of -Os out-of-line
173580 * powerpc.cc (Target_powerpc::Relocate::relocate): Correct address
173877 /* Return the address of the object we are currently observing. */
173898 address -- but one that does not fail in read_memory, due to the
174128 done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores
174129 the RA (return address) register on the stack, which is the information
174144 I guess riscv32 would use lw in such situation so this patch also adds
174656 want to guess so. And my very, very old paper doc doesn't even mention
174775 (rl78_special_reloc): Check that reloc address is within section.
174797 Because .debug_types doesn't provide any address ranges, these CUs can
175006 [gdb/symtab] Fix zero address complaint for shlib
175032 - in find_pc_sect_compunit_symtab we try to find the address
175070 When reading the first range 0x0..0x56, it doesn't trigger the "start address
175078 complaint (_(".debug_rnglists entry has start address of zero"
175099 and consequently, the CU addrmap gets build using address info from the
175127 This patch fixes the first problem encountered: fix the "start address of
175149 Fix zero address complaint.
175208 bfin pcrel24 relocs are weird, they apply to the reloc address minus
175323 The attach succeeds. I guess it is done before "set
175427 address size from that structure, but unfortunately that interface
175453 address size argument.
175532 that, we first need to address the issue of class users writing and
175539 address size from that object file, but unfortunately that interface
175542 Luckily, address size information is already available to the users
175543 through other means. As a result, the address size also needs to be a
175553 To address the problem of reading the dwarf_expr_context class
175629 extending the push object address functionality to accept any location
175738 (class dwarf_expr_context): Add object address member to
175746 (class dwarf_evaluate_loc_desc): Move object address member to
175868 the push object address functionality.
176042 address behind the some_variable variable, the constant value 0 is used
176054 address.
176426 debug output prints the host address of the used unwinder, which is not
179169 Fix printing of non-address types when memory tagging is enabled
179175 prints non-address values: composite types, floats, references, member
179197 an integer and convert it to an address, which #1 - doesn't make sense
179201 if the address-like value has tags.
179672 It's hard to be sure why this is done, but I would guess a combination
179832 JIT code objects except their load address. So the output looks a bit
180100 …#6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address …
180198 …#6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address …
180881 inside the object as soon as we put the object in the list, to address
181288 can lead to non-zero address at run-time.
181675 * po/gas.pot: Regenerate.
181682 * po/bfd.pot: Regenerate.