| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
writevalue didn't handle 64-bit values, dropping the high 32 bits,
and also wrote any value in the range [0,15] as 0.
* tekhex.c (first_phase): Handle *ABS* symbols.
(writevalue): Rewrite.
|
|
|
|
A few tests on the testsuite require dwarf5 to work. Up until now, the
way to do this was to explicitly add the command line flag -gdwarf-5.
This isn't very portable, in case a compiler requires a different flag
to emit dwarf5.
This commit adds a new option to gdb_compile that would be able to add
the correct flag (if known) or error out in case we are unable to tell
which flag to use. It also changes the existing tests to use this
general option instead of hard coding -gdwarf-5.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
This patch started as an attempt to allow the 'Size attribute to be
applied to types, and not just objects.
However, that turns out to be difficult due to the Ada semantcs of
'Size. In particular, Ada requires 'Size to denote the size of the
representation of the value, so for example Boolean'Size must be 1.
Implementing this properly requires information not readily available
to gdb... and while we could synthesize this information in many
cases, it also seemed to me that this wasn't strictly very useful when
debugging.
So instead, this patch adds support for the 'Object_Size attribute,
which is somewhat closer to 'sizeof'.
Note also that while 'Object_Size is defined for some dynamic types, I
chose not to implement this here, as again this information is not
readily available -- and I think it's preferable to error than to
print something that might be incorrect.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
originally the reason for pre-sizing was that that's easier
for a multi-threaded use of the hash table. That hasn't materialized
yet, so there's not much sense in using the very very conservative
estimates for pre-sizing. Doing the resize on-demand, whenever we
actually need to add a new entry doesn't change performance.
bfd/
merge.c (sec_merge_hash_insert): Resize as needed from here ...
(record_section): ... not from here. Don't calculate estimates,
return bool instead of three-state, regard all errors as soft
errors.
(_bfd_merge_sections): Adjust.
|
|
Remove the templated versions of 'find_thread', 'for_each_thread' and
'find_thread_in_random' and replace the template function argument with
'gdb::function_view'. The usage of 'gdb::function_view' produces less
cryptic messages on errors and documents well the types of the
parameters taken by the callback and its return type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I ran the testsuite with a patch setting dwarf_synchronous to false by
default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp
and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did
not show up as a result of the file command.
Fix this by forcing "maint set dwarf synchronous on".
Add the same in gdb.base/index-cache.exp, where this is also required.
Tested on aarch64-linux.
|
|
I ran into:
...
(gdb) pipe maint print objfiles self-spec | grep c1^M
name: c1^M
canonical: c1^M
qualified: c1^M
[3] ((addrmap *) 0xfffedfc1f010)^M
(gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index
...
Fix this by renaming the class from c1 to class1.
Tested on aarch64-linux.
|
|
When building gdb with -O2 -fsanitize=thread and running test-case
gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
...
(gdb) c&^M
Continuing.^M
(gdb) Quit^M
(gdb) quit_count=1
^M
Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
FAIL: $exp: no force memory write: \
SIGINT does not interrupt background execution
...
What happens is that:
- the breakpoint hits
- while evaluating the condition of the breakpoint,
$_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell
- in run_under_shell, a vfork is issued
- in the vfork child, execl executes the kill command
- in the vfork parent, waitpid is called to wait for the result of the kill
command
- waitpid returns -1 with errno set to EINTR
- run_under_shell doesn't check the result of waitpid, and returns the
value of local variable status. Since waitpid returned -1, status was
not assigned a value, so it's uninitialized, and happens to be
non-zero
- the breakpoint condition evaluates to true, because
$_shell("kill -INT <pid-of-gdb>") != 0
- the breakpoint triggers a stop, which the test-case doesn't expect.
Fix this by using gdb::handle_eintr to call waitpid in run_under_shell.
Also handle the case that waitpid returns an error other than EINTR, using
perror_with_name.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR gdb/30695
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
|
|
Local absolute symbols are resolved at assembly stage and the symbol
value is placed in the relocation addend. But non-zero addend will
cause an assertion failure during linking.
Forces emission of relocations to defer resolution of local abs symbols
until link time.
bfd/
* elfnn-loongarch.c (loongarch_elf_relax_section): Determine
absolute symbols in advance to avoid ld crash.
gas/
* config/tc-loongarch.c (loongarch_force_relocation): New
function to force relocation.
* config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros
to force relocation.
(loongarch_force_relocation): Function declaration.
* testsuite/gas/loongarch/localpic.d: New test.
* testsuite/gas/loongarch/localpic.s: New test.
|
|
|
|
With target board unix we get:
...
$ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \
-ex "info function operator\*"
All functions matching regular expression "operator\*":
File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
but with target board cc-with-dwz-m:
...
All functions matching regular expression "operator\*":
File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
The first operator:
...
$ c++filt _ZN3foomlERS_
foo::operator*(foo&)
...
matches address 0x410250 which is defined here in the CU in the exec:
...
<1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
<10f2> DW_AT_specification: <alt 0x93>
<10f6> DW_AT_decl_line : 72
<10f7> DW_AT_decl_column : 7
<10f7> DW_AT_object_pointer: <0x1106>
<10f9> DW_AT_low_pc : 0x410250
<1101> DW_AT_high_pc : 32
<1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<1104> DW_AT_call_all_calls: 1
...
and declared here in the PU in the .dwz file:
...
<2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
<94> DW_AT_external : 1
<94> DW_AT_name : operator*
<98> DW_AT_decl_file : 2
<98> DW_AT_decl_line : 10
<99> DW_AT_decl_column : 9
<9a> DW_AT_linkage_name: _ZN3foomlERS_
<9e> DW_AT_accessibility: 1 (public)
<9e> DW_AT_declaration : 1
<9e> DW_AT_object_pointer: <0xa2>
...
When creating a new symbol for the operator, the DW_AT_decl_file attribute is
looked up, and found to be 2.
The 2 is supposed to be mapped using the PU, which has this file name table:
...
The File Name Table (offset 0x78, lines 3, columns 2):
Entry Dir Name
0 0 <dwz>
1 1 stddef.h
2 2 cplusfuncs.cc
...
Instead, it's mapped using the CU, which has this file name table:
...
The File Name Table (offset 0x34, lines 3, columns 2):
Entry Dir Name
0 1 cplusfuncs.cc
1 1 cplusfuncs.cc
2 2 stddef.h
...
This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where
the same problem happens for two CUs.
Fix this by using the correct file name table.
Add a dwarf assembly test-case for PR25771.
Tested on aarch64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
|
|
As gdbreplay communicates with GDB, it outputs all the remote
protocol communication it reads from the remotelogfile to stderr.
This patch disables this behavior by default but adds the new
--debug-logging option which turns printing the packets
to stderr on again.
The motivation for this change is to make it possible to use
gdbreplay with TCL tests. Printing the whole remotelog file out
seems to overflow the expect cache wich causes gdbreplay to not
to get the packet its expects and results in going out of sync
with GDB. Other motivation is making communication between GDB
and gdbreplay faster as printing bigger remotelogfile takes
considerable amount of time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add handling of '.' in gdb/contrib/spellcheck.sh.
While we're at, simplify the sed invocation by using a single s command
instead of 3 s commands.
Also introduce sed_join and grep_join.
Fix the following common misspellings:
...
bandwith -> bandwidth
emmitted -> emitted
immediatly -> immediately
suprize -> surprise
thru -> through
transfered -> transferred
...
Verified with shellcheck.
|
|
Speed up gdb/contrib/shellcheck.sh by caching the grep pattern.
Without cached grep pattern:
...
$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c
real 0m2,750s
user 0m0,013s
sys 0m0,032s
...
and with cached grep pattern:
...
$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c
real 0m0,192s
user 0m0,022s
sys 0m0,024s
...
Tested on aarch64-linux.
|
|
Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell
check and bail out ASAP with an exit code of 1 if misspelled words were
found, or 0 otherwise.
Verified with shellcheck.
|
|
A question was asked on stackoverflow.com about the guile function
get-basic-type[1] which is mentioned in the docs along with an example
of its use.
The problem is, the function was apparently never actually added to
GDB. But it turns out that it's pretty easy to implement, so lets add
it now. Better late than never.
The implementation mirrors the Python get_basic_type function. I've
added a test which is a copy of the documentation example.
One issue is that the docs suggest that the type will be returned as
just "int", however, I'm not sure what this actually means. It makes
more sense that the function return a gdb:type object which would be
represented as "#<gdb:type int>", so I've updated the docs to show
this output.
[1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
|
|
When building gdb with -std=c++20 I run into:
...
gdb/dwarf2/cooked-index.c: In lambda function:
gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \
‘[=]’ is deprecated in C++20 [-Werror=deprecated]
471 | gdb::thread_pool::g_thread_pool->post_task ([=] ()
| ^
gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture
...
Fix this and two more spots by removing the capture default, and explicitly
listing all captures.
Tested on x86_64-linux.
|
|
|
|
There is an invalid assumption within 'maint info inline-frames' which
triggers an assert:
(gdb) stepi
0x000000000040119d 18 printf ("Hello World\n");
(gdb) maintenance info inline-frames
../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
... etc ...
The problem is this assert:
/* Stopped threads always have cached inline_state information. */
gdb_assert (it != inline_states.end ());
If you check out infrun.c and look in handle_signal_stop for the call
to skip_inline_frames then you'll find a rather large comment that
explains that we don't always compute the inline state information for
performance reasons. So the assertion is not valid.
I've updated the code so that if there is cached information we use
that, but if there is not then we just create our own information for
the current $pc of the current thread.
This means that, if there is cached information, GDB still correctly
shows which frame the inferior is in (it might not be in the inner
most frame).
If there is no cached information we will always display the inferior
as being in the inner most frame, but that's OK, because if
skip_inline_frames has not been called then GDB will have told the
user they are in the inner most frame, so everything lines up.
I've extended the test to check 'maint info inline-frames' after a
stepi which would previously have triggered the assertion.
|
|
I searched for spots using ".reset (new ...)" and replaced most of
these with std::make_unique. I think this is a bit cleaner and more
idiomatic.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Klaus Gerlicher<klaus.gerlicher@intel.com>
|
|
PR 32260
bfd/
* elfxx-target.h (bfd_elfNN_bfd_merge_sections): Default to
bfd_generic_merge_sections when using the generic linker.
* elflink.c (_bfd_elf_merge_sections): Return error from
_bfd_merge_sections. Abort on wrong hash table.
ld/
* ldlang.c (lang_process): Report bfd_merge_sections error.
|
|
|
|
This changes the DWARF reader to capture the current working directory
and the current debug directory. This avoids races when the DWARF
reader is working in the background.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
|
|
This patch adds a cwd paramter to openp, so that the current directory
can be passed in by the caller. This is useful when background
threads call this function -- they can then avoid using the global and
thus avoid races with the user using "cd".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
|
|
Currently, gdb_abspath uses the current_directory global. However,
background threads need to capture this global to avoid races with the
user using "cd".
This patch changes this function to accept a cwd parameter, in
prepration for this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
|
|
While trying to substitute some std::vector type A in the code with a
gdb::array_view:
...
- using A = std::vector<T>
+ using A = gdb::array_view<T>
....
I ran into the problem that the code was using A::iterator while
gdb::array_view doesn't define such a type.
Fix this by:
- adding types gdb::array_view::iterator and gdb::array_view::const_iterator,
- using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is
usual, and
- using them explicitly in a unit test.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
There's a plan to replace gdb::array_view with std::span (PR31422), and making
gdb::array_view more like std::span helps with that.
One difference is that std::span has:
...
constexpr iterator begin() const noexcept;
constexpr const_iterator cbegin() const noexcept;
...
while gdb::array_view has:
...
constexpr T *begin () noexcept;
constexpr const T *begin () const noexcept;
...
Fix this by renaming the second variant to cbegin, and making the first
variant const.
Likewise for gdb::array_view::end.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When building gdb with -std=c++20, I run into:
...
In file included from /usr/include/guile/2.0/libguile/__scm.h:479,
from /usr/include/guile/2.0/libguile.h:31,
from /data/vries/gdb/src/gdb/guile/guile-internal.h:30,
from /data/vries/gdb/src/gdb/guile/guile.c:37:
/usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \
scm_cell(scm_t_bits, scm_t_bits)’:
/usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \
assignment with ‘volatile’-qualified left operand is deprecated \
[-Werror=volatile]
98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
| ~~~~~~~~~~~~~~~~~~~^~~~~
...
This was reported upstream [1].
Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the
default SCM_DEBUG_TYPING_STRICTNESS == 1.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR guile/30767
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333
|
|
Consider test-case gdb.dwarf2/local-var.exp. The corresponding source
contains a function with a local variable:
...
program test
logical :: local_var
local_var = .TRUE.
end
...
Currently, the local variable shows up in the cooked index:
...
[2] ((cooked_index_entry *) 0xfffec40063b0)
name: local_var
canonical: local_var
qualified: local_var
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0xa3
parent: ((cooked_index_entry *) 0xfffec4006380) [test]
...
making the cooked index larger than necessary.
Fix this by skipping it in cooked_indexer::index_dies.
Tested on aarch64-linux.
PR symtab/32276
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276
|
|
|
|
Hannes pointed out that gdb.execute_mi() will crash.
This patch fixes the bug.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
As soon as I committed Zhaoxin's patch, I realized that I did not
include the regen file. Regenerate them and commit as obvious.
opcodes/ChangeLog:
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
|
|
gas/ChangeLog:
* NEWS: Support ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New comment.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
|
|
Fix a bug where the main program does not free the rows of
the matrix. The memory for thread_data_arguments is also
not released. In function check_results, the memory for the
marker vector is not released.
The usage of the verbose veriable has been extended to
print more messages.
gprofng/ChangeLog
2024-10-16 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR 32273
PR 32274
* mxv-pthreads/src/main.c: add calls to free() to
release the memory allocated for array A and vector
marker. Improve the usage of the verbose variable.
* mxv-pthreads/src/manage_data.c: add a diagnostic
printf statement.
* mxv-pthreads/src/mydefs.h: adapt prototype to
match the changes in main.c.
|
|
|
|
Say we simulate a bad alloc in gdb_bfd_init_data:
...
+ {
+ static bool throw_bad_alloc = true;
+ if (throw_bad_alloc)
+ {
+ throw_bad_alloc = false;
+
+ va_list dummy;
+ throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
+ }
+ }
gdata = new gdb_bfd_data (abfd, st);
...
That works out fine for doing "file a.out" once:
...
$ gdb -q -batch -ex "file a.out"
bad alloc
$
...
but doing so twice get us:
...
$ gdb -q -batch -ex "file a.out" -ex "file a.out"
bad alloc
Fatal signal: Segmentation fault
----- Backtrace -----
0x5183f7 gdb_internal_backtrace_1
/home/vries/gdb/src/gdb/bt-utils.c:121
0x5183f7 _Z22gdb_internal_backtracev
/home/vries/gdb/src/gdb/bt-utils.c:167
0x62329b handle_fatal_signal
/home/vries/gdb/src/gdb/event-top.c:917
0x6233ef handle_sigsegv
/home/vries/gdb/src/gdb/event-top.c:990
0xfffeffba483f ???
0x65554c eq_bfd
/home/vries/gdb/src/gdb/gdb_bfd.c:231
0xeaca77 htab_find_with_hash
/home/vries/gdb/src/libiberty/hashtab.c:597
0x657487 _Z12gdb_bfd_openPKcS0_ib
/home/vries/gdb/src/gdb/gdb_bfd.c:580
0x6272d7 _Z16exec_file_attachPKci
/home/vries/gdb/src/gdb/exec.c:451
0x627e67 exec_file_command
/home/vries/gdb/src/gdb/exec.c:550
0x627f23 file_command
/home/vries/gdb/src/gdb/exec.c:565
Segmentation fault (core dumped)
$
...
The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache:
...
if (bfd_sharing)
{
slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT);
gdb_assert (!*slot);
*slot = abfd;
}
gdb_bfd_init_data (abfd, &st);
...
while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is
not properly initialized.
Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after
a successful call to gdb_bfd_init_data, such that we get:
...
$ gdb -q -batch -ex "file a.out" -ex "file a.out"
bad alloc
$
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When building gdb with gcc 12 and -fsanitize=threads while renabling
background dwarf reading by setting dwarf_synchronous to false, I run into:
...
(gdb) file amd64-watchpoint-downgrade
Reading symbols from amd64-watchpoint-downgrade...
(gdb) watch global_var
==================
WARNING: ThreadSanitizer: data race (pid=20124)
Read of size 8 at 0x7b80000500d8 by main thread:
#0 cooked_index_entry::full_name(obstack*, bool) const cooked-index.c:220
#1 cooked_index::get_main_name(obstack*, language*) const cooked-index.c:735
#2 cooked_index_worker::wait(cooked_state, bool) cooked-index.c:559
#3 cooked_index::wait(cooked_state, bool) cooked-index.c:631
#4 cooked_index_functions::wait(objfile*, bool) cooked-index.h:729
#5 cooked_index_functions::compute_main_name(objfile*) cooked-index.h:806
#6 objfile::compute_main_name() symfile-debug.c:461
#7 find_main_name symtab.c:6503
#8 main_language() symtab.c:6608
#9 set_initial_language_callback symfile.c:1634
#10 get_current_language() language.c:96
...
Previous write of size 8 at 0x7b80000500d8 by thread T1:
#0 cooked_index_shard::finalize(parent_map_map const*) \
dwarf2/cooked-index.c:409
#1 operator() cooked-index.c:663
...
...
SUMMARY: ThreadSanitizer: data race cooked-index.c:220 in \
cooked_index_entry::full_name(obstack*, bool) const
==================
Hardware watchpoint 1: global_var
(gdb) PASS: gdb.arch/amd64-watchpoint-downgrade.exp: watch global_var
...
This was also reported in PR31715.
This is due do gcc PR110799 [1], generating wrong code with
-fhoist-adjacent-loads, and causing a false positive for
-fsanitize=threads.
Work around the gcc PR by forcing -fno-hoist-adjacent-loads for gcc <= 13
and -fsanitize=threads.
Tested in that same configuration on x86_64-linux. Remaining ThreadSanitizer
problems are the ones reported in PR31626 (gdb.rust/dwindex.exp) and
PR32247 (gdb.trace/basic-libipa.exp).
PR gdb/31715
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31715
Tested-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
|
|
While looking at the cooked index entry for local variable l4 of function test
in test-case gdb.fortran/logical.exp:
...
$ gdb -q -batch outputs/gdb.fortran/logical/logical \
-ex "maint print objfiles"
...
[9] ((cooked_index_entry *) 0x7fc6e0003010)
name: l4
canonical: l4
qualified: l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7fc6e0002f20) [test]
...
I noticed that while the entry does have a parent, that's not reflected in the
qualified name.
This makes it harder to write test-cases that check the parent of a cooked
index entry.
This is due to the implementation of full_name, which skips printing
parents if the language does not specify an appropriate separator.
Fix this by using "::" as default separator, getting us instead:
...
[9] ((cooked_index_entry *) 0x7f94ec0040c0)
name: l4
canonical: l4
qualified: test::l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7f94ec003fd0) [test]
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
gprofng/ChangeLog
2024-10-14 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* doc/Makefile.am: Use install-data-local to install gprofng examples.
* doc/Makefile.in: Rebuild.
|
|
the way the overflow check was written wasn't understood by some
GCC versions and produced false positives for the memset call being
called potentially with object sizes that are larger than half
address-space.
|
|
if the input sections are near the max supported size (4G)
we might fail to enlarge the hash table. The error handling
for this case didn't quite work. When this happens we can
gracefully fall back to just not deduplicate this section
(and continue with further mergable sections). We were mixing
that with the case of not being able to even allocate a small
structure (in which case we can as well error out completely),
this disentables both cases.
bfd/
PR ld/32260
* merge.c (sec_merge_maybe_resize): Check overflow in ultimate
target type.
(record_section): Return three-state, use new state when unable
to enlarge hash table.
(_bfd_merge_sections): Remove current section from merging
consideration when hashtable can't be enlarged.
|
|
When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run
into:
...
(gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1
get_compiler_info: gcc-7-5-0
p Float(Another_Fixed) = Float(Another_Delta * 5)^M
No definition of "another_delta" in current context.^M
(gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed
...
This is a regression since commit 1411185a57e ("Introduce and use
gnat_version_compare"), which did:
...
# This failed before GCC 10.
- if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} {
+ if {$scenario == "all" && [gnat_version_compare < 10]} {
gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \
"value of another_fixed"
}
...
Fix this by using gnat_version_compare >= 10 instead.
Tested on x86_64-linux, with gcc 7 - 13.
|
|
Building shared libraries should not be allowed for PC-relative
relocations against external symbols.
Currently LoongArch has no corresponding checks and silently
generates wrong shared libraries.
However, In the first version of the medium cmodel, pcalau12i+jirl was
used for function calls, in which case PC-relative relocations were
allowed.
|
|
|
|
|
|
PR gprofng/32241
* src/Makefile.am (CSOURCES): Remove dbe_memmgr.c
* src/Makefile.in: Regenerate.
* src/dbe_memmgr.c: Remove.
* src/gprofng.cc (main): Call xmalloc_set_program_name.
* src/gp-archive.cc (main): Likewise.
* src/gp-collect-app.cc (main): Likewise.
* src/gp-display-src.cc (main): Likewise.
* src/gp-display-text.cc (main): Likewise.
* src/Application.cc: Use xmalloc, xrealloc, xcalloc, xstrdup,
xstrndup instead of malloc, realloc, calloc, strdup, strndup.
* src/BaseMetric.cc: Likewise.
* src/CallStack.cc: Likewise.
* src/ClassFile.cc: Likewise.
* src/Data_window.cc: Likewise.
* src/Dbe.cc: Likewise.
* src/DbeJarFile.cc: Likewise.
* src/DbeSession.cc: Likewise.
* src/DbeView.cc: Likewise.
* src/DerivedMetrics.cc: Likewise.
* src/DwarfLib.cc: Likewise.
* src/Elf.cc: Likewise.
* src/Emsg.cc: Likewise.
* src/Experiment.cc: Likewise.
* src/Function.cc: Likewise.
* src/Module.cc: Likewise.
* src/Print.cc: Likewise.
* src/QLParser.yy: Likewise.
* src/SAXParserFactory.cc: Likewise.
* src/Settings.cc: Likewise.
* src/SourceFile.cc: Likewise.
* src/StringBuilder.cc: Likewise.
* src/StringMap.h: Likewise.
* src/Table.cc: Likewise.
* src/checks.cc: Likewise.
* src/collctrl.cc: Likewise.
* src/comp_com.c: Likewise.
* src/count.cc: Likewise.
* src/envsets.cc: Likewise.
* src/gp-archive.cc: Likewise.
* src/gp-display-src.cc: Likewise.
* src/gp-display-text.cc: Likewise.
* src/gprofng.cc: Likewise.
* src/ipc.cc: Likewise.
* src/ipcio.cc: Likewise.
* src/vec.h: Likewise.
* src/util.cc: Likewise.
(get_prog_name): Remove.
* src/util.h: Likewise.
* src/dbe_hwc.h (malloc, realloc, calloc, strdup): Define.
|
|
This is the assertion that vars->string_ptr < vars->end_string_ptr,
ie. when it fails we've overflowed the string buffer area. Caused by
allocating space for import_name but writing symbol_name, and they can
be different.
* peicode.h (SIZEOF_ILF_STRINGS): Revert 042f14505e change.
|
