Lines Matching +refs:po +refs:say +refs:location +refs:depth
791 - GAS instructions carry location information (file name and line
1367 underscore, but it seemed easier just to say no double underscores.
1995 insert the breakpoint/catchpoint location. This patch is a fix to the same.
3800 4) Check out */po/*.pot which we don't update frequently.
7284 stored in the debug info for this location.
7302 Symbol "i" is multi-location:
7745 function into the option_def::var_address::enumeration location,
7893 Let's say the user wants to read the ebx register on amd64. ebx is a pseudo
7929 say "I don't know".
11183 However, the docs clearly say that only strings within the returned
13921 coarse-grained units (say, one per kernel module, even if a module consists
15045 location where GDB would normally expect to find it. GDB
15108 b. Install debug information into a location that step #1 or #2
15339 a breakpoint in function callee. The reported location where the
15340 breakpoint is set may be at the requested location in callee or the
15341 location in caller after callee has been inlined. The test needs to
15342 accept either location as correct provided the breakpoint address is not
15348 breakpoint location is reported is callee.adb. If the breakpoint is
15350 location in callee where it is inlined into caller.
16752 location. But PLT code is generated later than the stubs so we always
17133 location_completer function, however, the disassemble docs say:
17137 Expressions.), not location specs (*note Location Specifications::).
17266 * po/bfd.pot: Regenerate.
17281 * po/bfd.pot: Regenerate.
17295 * po/bfd.pot: Regenerate.
18736 resulting in the inferior seemingly stopping at a different location.
18738 This patch adds a nop line in the relevant location so we don't need to
20688 range and location lists that can segfault when debug_info_p is NULL.
21326 in that prefix but also in the distro's default location (typically,
22063 sense to say that the archive has disappeared.
24750 location is most likely wrong.
24821 Not all breakpoints have a source location. For example, a breakpoint
25192 saying that the stop location may not be precise.
29268 by reversing from the current location and checking all registers for
29302 Which is clearly using the incorrect rbp to find the memory location of
29339 and the test to accept either line as a correct step location.
29609 gdb: don't always print breakpoint location after failed condition check
29613 user would see two stops reported, the first at the location where the
29614 signal occurred, and the second at the location of the breakpoint.
29616 By default GDB remains at the location where the signal occurred, so
29625 stack back to the location where the inferior function call started.
29627 location of the breakpoint, not at the location where the signal
29631 GDB reports a single stop event at the location of the breakpoint,
29638 notification will be for the location where the inferior call stopped,
29639 which will be the location at which the signal occurred.
29730 This is the broken state. GDB is reports the SIGSEGV location, but
29731 not the unwound breakpoint location. The final 'bt 1' shows that the
29732 inferior is not located in cond_fail, which is the only location GDB
29756 This is better. GDB now reports a single stop at the location of the
29783 correct location, and the error message describes which signal caused
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.
31534 the *_current_source function always looks up a location based on the
31535 current thread's location -- if a user is asking the current thread to
32069 gprofng: pass gprofng location to gp-display-gui
32129 breakpoints, albeit at a different location in linux-low.cc. Testing
33271 gdb, breakpoint: add breakpoint location debugging logs
33278 breakpoint location insertion and removal flow.
34493 gdb: don't always print breakpoint location after failed condition check
34534 …dbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"}
34557 …dbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"}
36353 In a review [1], I pointed out that applying the patch, git would say:
38706 * object.cc (Relocate_info::location): Always report section+offset.
39042 self-contained way to ask GDB to print the location where the inferior is
39690 gdb: include location number in breakpoint error message
39706 This commit extends takes this further, and includes the location
39712 only has a single location then the location number is not included,
40672 application core file represents threads. Thus, we might say, a
41564 version of the ABI spec, and such usages are all fixed to say just $r21
41910 This works for pltN entry of size, say, less than 16 bytes. But if the
44381 <2dfa5> DW_AT_location : 0x27cf1 (location list)
44387 Looking at the location list, I see:
44451 work for a pltN entry of size say, 16 bytes).
46066 location of contents and relocs.
46067 (ppc64_elf_relocate_section): Adjust for changed location of
46608 used to say, it would notify all MI interpreters. Now, it's easy to
47569 location list, while maintaining reasonably good encapsulation.
47641 surprisingly big number of places that access the first location of
47643 the possibility of multi-location breakpoints, I don't know. But
47659 location
47661 location
47663 one location
47707 gdb: get gdbarch from syscall_catchpoint instead of location
47819 solution in this commit is to select the location in the current symtab.
49187 If this location happens to be on the same page as the page that the
49892 situation where a location expression does not describe all the bits
50456 gdbserver: Clear upper ZMM registers in the right location.
50716 Or a location where the test script was matching part of the newline
50781 location expression.
51624 …lname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"}
53465 construct of the "set language" command to say "pick the appropriate
53639 [ Note that when doing a resize by say maximizing or de-maximizing a terminal,
54356 Let's say inferior 2 is selected by do_target_wait and returns an event that is
54944 of the left margin is not written, which is a problem because that location is
56234 under bfd/po/, i.e. in maintainer mode.
56372 gdb: don't always print breakpoint location after failed condition check
56415 actually stopped at a location of breakpoint 1, which is not the case.
56512 current location. The second time is a little odd, why do we print
56684 some_func, and it's certainly not located at the breakpoint location.
56843 I say "could, in theory," because currently GDB stops the prologue
57916 same operand. But if we get to operand 3 (say) and see a register
58540 comment to say that we call unpack_pointer. I've also adjusted the
58620 for the current location within the pending frame, or None.
59614 In do_self_tests we try to find out the location of the gdb to debug, which
59617 In principle, the host board specifies the location of GDB, on host.
60345 which case the gdbarch will still say we support pointer authentication but we
60406 That's fine for say:
60542 - downloading to a location which is safe for parallel testing, by
60568 so the location of the second stub is known at build time, this may
60598 more appropriate location).
61152 However, notice, I did say, we don't often see this problem. Once I
61207 bug reported, but implemented in a different location within GDB.
61209 cp_symbol_name_matches_1. I believe this is a better location as it
61463 Regen ld/po/BLD-POTFILES.in
61789 describes roughly "how do we ask the target to insert that location".
62123 say much about what happens if/when an inferior function call is
62191 'unwinders' when it should say 'unwinder' in one case.
63413 gprofng: PR30195 [display text] Source code location can not be found
63423 Some systems may install binutils headers into a system location
65421 (gdb) watch -location y^M
65422 Hardware watchpoint 2: -location y^M
65423 (gdb) PASS: gdb.rust/watch.exp: watch -location y
65427 (gdb) watch -location y^M
65428 Watchpoint 2: -location y^M
65429 (gdb) FAIL: gdb.rust/watch.exp: watch -location y
65433 gdb_test "watch -location y" ".*watchpoint .* -location .*"
65589 I say "as expected" because the number was set to zero. But, even if
65704 …pendshr.c:pendfunc2",cond="x==4",evaluated-by="host",times="0",original-location="mi-pendshr.c:pen…
65806 When creating a thread-specific breakpoint with a single location, the
65820 times="0",original-location="bar"}
66499 point to it, so we can say that the thread exited meanwhile.
68367 - non-gcc producers (say, clang).
68903 But that already doesn't compile with say glibc 2.31, and regardless I think
69230 However, when the inferior is running on the background, say with
70970 for the breakpoint, one location will be within the function itself as
70971 we would expect, but the other location will be within the PLT table
71219 instead say 'thread 2.1' which corresponds to how the user specified
71613 location calculation.
71627 Integer overflow in data location calculation
71629 Integer overflow in data location calculation
72690 gdb: fix display of thread condition for multi-location breakpoints
72711 Notice that, at the end of the location for breakpoint 3, the 'thread
72741 The 'thread 1' condition is now displayed at the end of each location,
72742 which makes the output the same for single location breakpoints and
72743 multi-location breakpoints.
72927 I haven't updated the manual, we don't explicitly say that these
73537 an error if called while not at an svr4 probe location, and therefore
74849 window isn't in the current layout, then GDB will say it doesn't
75295 gprofng: PR30043 libgprofng.so.* are installed to a wrong location
79298 * po/SRC-POTFILES.in: Regenerate.
82445 Regen opcodes/po/POTFILES.in
83187 to a location for output.
83467 In this commit I will provide a partial fix for the problem. I say
84094 as_*_where(), as the functions can't know whether the passed in location
84789 applied to the same location, relocs that may appear somewhere other
85477 to an unexpected location.
85563 needed (compared to say i386, or ARM).
85603 plt location. Won't occur in real object files.
85930 * po/POTFILES.in: Likewise.
85980 0000002a v000000000000000 v000000000000000 location view pair
85981 0000002c v000000000000000 v000000000000000 location view pair
86406 parameter i, for which we find location list entries:
87100 probe, and the call to the old style breakpoint location were
87125 watch -location value task 3^M
87126 Watchpoint 2: -location value^M
87127 (gdb) PASS: gdb.ada/task_watch.exp: watch -location value task 3
87138 watch -location value task 3^M
87139 Hardware watchpoint 2: -location value^M
87605 The debug info says that the variable can be found at some stack location, but
87610 Note that marking the variables as volatile doesn't change the location
88806 …Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum $_hit_locno PR breakpoints…
88818 locno is printed when the breakpoint hit has more than one location.
88824 and location number.
88830 In case the breakpoint has only one location, $_hit_locno is set to
88833 to disable the breakpoint even when the breakpoint has only one location.
88836 one location,
88839 breakpoint having only one location.
88846 for a breakpoint with a single location.
88855 - Use 'code location' instead of 'location'.
88861 - Use 'code location' instead of 'location'.
89101 not already stopped at the breakpoint location, so I've added some
89840 - copy the file $f.bz2 into the desired location $dir/$f.bz2, and
90564 gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?
91895 depth=10
91940 reduce unnecessary debug information. In these cases, GDB would just say
92191 report the support, if the underlying target does not say it supports
93982 loc 4: b->address = 0x0 <-- location pointed to by global_ptr_ptr
95136 at a depth of 5 which we end up ignoring when summarizing. Rather
95887 * po/hu.po: Updated Hungarian translation.
96306 Regen ld/po/BLD-POTFILES.in
96988 the call. Thus, we never cache the base location as locate_base() had
98763 If we change the prefix string to a no-match, say "1 = ", and update the
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.
99922 This location of supervisor instructions is out of place (because many other
100737 section, this means that the there are 3 optional location
100741 However, this is not true, one of the location specifications must be
100742 given, i.e. we can't choose to give NO location specification, which
100753 By placing all the location specifications within '( ... )' we
101822 warnings in _bfd_per_xvec_warn location.
101852 entries to describe the location of the user stack for the initial
102487 a different location, it registers as a failure. Seeing as along with
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).
103311 to firefox. From the bug report, the messages all say:
103977 stops, however it was still testing for a specific location. The clang
103979 different stopping location, depending on the used compiler. With this
104381 The problem is a GCC bug, filed as "PR98148 - [AArch64] Wrong location
104551 Work around this (for say gas 2.39) by explicitly specifying the prototype for
106769 and was then running to an unexpected location.
107403 …nutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"}
107404 …est.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}
107407 …t.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]}
107915 location (exprloc)
109781 incorrect location information.
110157 out of scope (GC'd/dealloced), and the location
110191 owner: location owner's Python companion object
110193 address: installed address of the location
110194 function: function name where location was set
110195 fullname: fullname where location was set
110196 thread_groups: thread groups (inferiors) where location was set.
110199 enabled: get/set enable/disable this location (bool)
110606 breakpoint with a location, so the regexp returned by
110716 commit failed to update one location in py-disasm.c though.
111461 reading memory at the location the breakpoint could be placed.
111481 breakpoints being placed in the wrong location.
112272 there's no way to detect the removal of an objfile, say when the
112452 That doesn't seem to matter much for this example, but for say 10 threads and
113233 The problem is that the written fields are part of the same memory location as
113250 currently follow it can be merged in the same memory location as the
113292 location as the read fields, so executing a read and write in
114918 Support for location and range lists for split-dwarf and dwarf-5.
114919 Adding support for location and range lists for split-dwarf and dwarf-5.
115028 Add get/set member functions for the two fields as a convenient location to
115148 read_comp_units_from_section is not used (run the test-case with say, target
115161 say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".
115653 Even if MS docs say that CP_UTF8 should always be used on newer
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
116382 ...points to a "sibling" DIE that is at a different child depth.
116734 now restored in a different location is ui::async, before this commit
117058 either inputs (if the .o files have the same name, say if they are
117149 Binutils support for dwarf-5 (location and range lists related)
117343 …/home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET…
117435 location.c, so they are moved to the header. Since the definitions of
117454 Currently, GDB internally uses the term "location" for both the
117455 location specification the user input (linespec, explicit location, or
117456 an address location), and for actual resolved locations, like the
117457 breakpoint locations, or the result of decoding a location spec to
117461 breakpoint::location;
117464 "location" is the location spec, and "loc" is the resolved locations.
117469 The location spec type is presently called event_location:
117472 event_location_up location;
117484 with stop events. E.g., "list" works with location specs.
117488 location spec, they are renamed to include "spec" in their name, like
117489 e.g., "location" -> "locspec". Similarly, functions that work with
117490 location specs, and currently have just "location" in their name are
118169 The var-create command samples the value of the variable at a location where
118894 frame offset (at 0xA8 relative to R0 location) as well as FPU
120203 but that only works if the stack location happens to be unequal to 12 before
121252 Explicitly mention yet-unloaded shared libraries in location spec examples
121342 gdb/manual: Introduce location specs
121345 "Several @value{GDBN} commands accept arguments that specify a location
121348 And then, such commands are documented as taking a "location"
121351 @item break @var{location}
121352 @item clear @var{location}
121353 @item until @var{location}
121354 @item list @var{location}
121355 @item edit @var{location}
121356 @itemx info line @var{location}
121357 @item info macros @var{location}
121358 @item trace @var{location}
121359 @item info scope @var{location}
121360 @item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
121362 The issue here is that "location" isn't really correct for most of
121363 these commands. Instead, the "location" argument is really a
121365 "linespecs", "explicit location", and "address location" input
121367 (plural) in the program that match. For example, a "location"
121371 libraries of all the inferiors. A location specified like "-function
121376 "location", actually end up working with multiple locations, and the
121379 command aborts with an error if the location specification resolves to
121382 location (which sounds like should be improved).
121389 based on the user-specified location spec. Then use "location
121390 specification or the shorter "location spec" thoughout instead of
121391 "location" when we're talking about the user input.
121399 corresponding shorthand "location spec", as something distinct from
121400 an actual code location in the program. It explains what a concrete
121401 code location is. It explains that a location specification may be
121403 program, or no code location at all. It gives examples. Some
121407 section, since all the other commands that accept a location spec
121410 - Goes through the manual, and where "@var{location}" was used for a
121411 command argument, updated it to say "@var{locspec}" instead. At the
121413 describe what happens when the location spec resolves to more than
121414 one location. Most commands just did not say anything about that.
121416 One command -- "maint agent -at @var{location}" -- currently says it
121417 accepts a "location", suggesting it can accept address and explicit
122466 breakpoint location.
123028 location using add_dummy_location.
123032 location's gdbarch, so replace the references to loc->gdbarch (which
123047 Make breakpoint_address_bits look at the location kind
123048 Software watchpoints allocate a special dummy location using
123050 breakpoint_address_bits checks whether the location is that special
123051 location to decide whether the location has a meaninful address to
123054 Introduce a new bp_loc_software_watchpoint location kind, and make
123217 breakpoint's location. Do that directly.
123276 7.0 and may change -- that's long enough ago that I think we can say
124236 || bfd_bwrite (location, count, abfd) != count)
125812 [gdb/testsuite] Fix gdb.dwarf2/locexpr-data-member-location.exp with nopie
125813 When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
125818 (gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
125829 gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
126556 We would now say:
126891 and furthermore can be distinguished by their event location.
127120 - we set breakpoint, expect 2 locations, but only one location is
127215 I'd say clean_up_just_stopped_threads_fsms is the culprit here. It
127417 (say, two arrays of different sizes with the same name in two different
128628 expected location") introduced some DUPLICATEs in MI tests using
128633 These test names were previously differentiated by the location passed
128634 to mi_continue_to_line. Since the location can contain a path, that
128635 commit removed the location from the test name, in favor of a hardcoded
129302 gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected location
129308 …a/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b …
129319 stopped at an unexpected location. But it starts failing with this
131102 The problem is that the bar breakpoint ends up at an unexpected location
131351 I have my debuginfod library installed in a non-standard location
131617 The problem is that the libthread_db message occurs at a location where it's
132073 doesn't make much sense to allow the user to say "no, I don't want to
132781 (that it must have received from somewhere else simultaneously), say
133068 Looking at the line-table for this location, we have:
133896 location.
134546 (calc_fixup): Return a size_t. Adjust to suit new location of
134548 (microblaze_elf_relax_section): Adjust to suit new location of
134564 Regen bfd po/SRC-POTFILES.in
136884 * gprofng/src/envsets.cc (putenv_libcollector_ld_misc): New location of
137920 * po/SRC-POTFILES.in: Regenerate.
139221 backends don't extract the return value from the correct location. GDB should
139222 fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf.
139821 and the actual location of the source file in the debuginfod client cache.
139856 -stack-info-depth --thread 3
139857 ^done,depth="4"
141861 a compilation unit (or at least the location of a corresponding source
142583 python.c so GDB can find the functions in their new location.
142965 that the new location is not a statement, and that the new location is
143299 I say sometime, because, gdb_readline_no_editing_callback already
144200 Finally, I noticed that the docs for 'win info' don't explicitly say
144741 So, this commit adds a comment in location.c mentioning that the
144779 'task 123' is passed to string_to_event_location in find a location
144780 specification. However, this location parsing understands about
144785 As a result, the location we get back from string_to_event_location
144786 has no actual location specification attached to it. The actual call
144796 location. As such, in new_linespec_location, the spec_string field of
144797 the location is left as nullptr.
144819 This will place a breakpoint at the current location with the
144841 a location specification.
145300 default location of the signal code instead. The youngest affected
145917 That kind of sucks, we say it's undocumented, then proceed to print
146790 think it will be better implemented in a more common location.
146849 Remove EL_* macros from location.c
146850 This patch removes the old-style EL_* macros from location.c. This
146858 Remove a use of xfree in location.c
146859 This small cleanup removes a use of xfree from location.c, by
146861 location.c, so it is made static. And, another function is changed to
148653 explicit test name at another location in the file since it also just
149048 same location. Fix this by only inserting the breakpoint once.
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.
149815 This now uses the thread_obj in its new location instead.
150355 out */po/*.pot which we don't update frequently.
151204 each field. Unfortunately, in some cases the field location is not
151241 location type for this field is a DWARF_BLOCK.
151372 cause the messages to be nested to an appropriate depth when other
152685 gdb: add accessors for field (and call site) location
153113 succeeding to to run to the specified location, but emit a FAIL when
154130 - copy say, gdb.arch/i386-avx.c as basis for a new test-case
154137 updated to say, 64 bytes. The initial PASS occurred only because the actual
155198 (md_assemble): Record the location of the instruction in
155768 but I'm not brave enough to say that it can never happen. If it does
156963 * po/BLD-POTFILES.in: Regenerate.
156964 * po/SRC-POTFILES.in: Regenerate.
156969 * po/fr.po; Updated French translation.
157080 target has been pushed, and in another location (in target.c) it seems
157373 * po/Make-in (msgid-bugs-address): Likewise.
157377 * po/Make-in (msgid-bugs-address): Update.
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.
158505 Pick up the elfutils/debuginfod.h install location -I flags from
159748 say the test fails on all targets. WIth multitarget testing, the
159826 Fix build with current GCC: EL_EXPLICIT(location) always non-NULL
159829 src/gdb/location.c: In function 'int event_location_empty_p(const event_location*)':
159830 …src/gdb/location.c:963:38: error: the address of 'event_location::<unnamed union>::explicit_loc' w…
159831 963 | return (EL_EXPLICIT (location) == NULL
159833 src/gdb/location.c:57:30: note: 'event_location::<unnamed union>::explicit_loc' declared here
159840 /* An explicit location. */
159976 * po/POTFILESin: Regenerate.
160668 complete enough to say why. I'll trust that whoever implemented it
161318 gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm.
161377 things have been added, line 770 now points at some random location in
162176 During symbol reading: location description stack overflow
162177 During symbol reading: location description stack underflow
162182 -re "\r\nDuring symbol reading: location description stack underflow" {
162184 -re "\r\nDuring symbol reading: location description stack overflow" {
162892 [gdb/symtab] Handle DW_AT_string_length with location list
162924 <2d7> DW_AT_string_length: 0xbf (location list)
162927 where the DW_AT_string_length is a location list, a case that is not handled
163152 location prepended to RPATH too, as also expected.
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.
163773 times="0",original-location="pendfunc1"}^M
164123 The "add accessors for field (and call site) location" patch caused a
164393 if sysroot is empty, no second lookup of the same location is performed.
165454 gdb: add accessors for field (and call site) location
165455 Add accessors for the various location values in struct field. This
165456 lets us assert that when we get a location value of a certain kind (say,
165457 bitpos), the field's location indeed contains a value of that kind.
165467 "location" structure that can be used at both places.
165470 bitpos location with value 0. While writing this patch, I tried to make
165471 it default to an "unset" location, to catch places where we would miss
165472 setting a field's location. However, I found that some places relied on
165475 "bitpos 0" location.
165481 TYPE_FIELD_BITPOS before checking if the location is of the bitpos
165788 And if there's say, a PASS that should actually be FAILing, it's hard to
165938 When GDB's inferior object is deleted (say the inferior exits) then
166243 location, we run into a testsuite failure in gdb.trace/entry-values.exp.
166262 the second location in struct call_site.
167483 what is used in say, continue_to_breakpoint.
168122 start, we record the symtab of the starting location. When the program
168138 expected to have a location in each inferiors. Without the fix, when
168140 single location.
169160 This patch fixes it, by running subst on the location list body, in
170696 [gdb/testsuite] Generate .debug_aranges in gdb.dwarf2/locexpr-data-member-location.exp
170697 When running test-case gdb.dwarf2/locexpr-data-member-location.exp with target
170701 Starting program: locexpr-data-member-location ^M
170702 warning: Section .debug_names in locexpr-data-member-location-lib.so has \
170708 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
170712 gdb.dwarf2/locexpr-data-member-location.exp.
171782 gdb.dwarf2/locexpr-data-member-location.exp, we run into:
171816 gdb.dwarf2/locexpr-data-member-location.exp fails like this:
171818 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
171831 Unexpected type field location kind: 4^M
171861 gdb.dwarf2/locexpr-data-member-location.exp fails like this:
171863 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
171886 FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
172023 fmt=0xc520c0 "Unexpected type field location kind: %d")
172374 * po/BLD-POTFILES.in: Regenerate.
173408 On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the
174201 GDB did move past the branch-link location thus making forward progress.
174869 say: not crippling for the most part, but makes certain tasks more
175391 expected to be in a form of a value and not location description.
175437 value object that describes a location. To do this, the method requires
175558 represent both values and a location descriptions and why it is not
175563 infrastructure to resolve composite and implicit pointer location
175568 all infrastructure for those location descriptions to the expr.c file
175582 While implicit pointer location descriptions are still not useful in
175584 location descriptions are certainly necessary to describe a results of
175629 extending the push object address functionality to accept any location
175856 location description.
175861 a full support for all location description types.
175867 location descriptions as well as using any location description for
175900 location description types, which means that a vendor extended CFI
175901 rules could support composite location description as well. This also
175995 the location description evaluator.
176016 the location description evaluator) with a missing frame information.
176035 location of another variable. Depending on a value of some_variable, the
176036 variable whose location is described by this expression is either read
176038 the value will be returned as an implicit location description on the
176053 be 0, the variable location could be defaulted to a TLS based memory
176078 Similarly to the previous scenario, the location of a variable A is an
176079 implicit location description with a constant value that depends on a
176156 The new analysis requires the DWARF location description for the
176176 DWARF location expression.
177331 when calculating string table file location.
181675 * po/gas.pot: Regenerate.
181682 * po/bfd.pot: Regenerate.
181908 Python 3.3 and finaly removed in Python 3.8. The guidelines say to