commit 3c5fce9bc2
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Apr 21 12:00:55 2017 -0700
Require --no-dynamic-linker with -static -E/--dynamic-list
added pr21086.c and pr21086.list without wiring them up. Wire them up to
verify that there is no dynamic section with -static -E/--dynamic-list.
PR ld/21086
PR ld/33630
* testsuite/ld-elf/pr21086.rd: New file.
* testsuite/ld-elf/shared.exp: Wire PR ld/21086 test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
commit dda8ddc56f
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Nov 20 22:17:27 2012 +0000
Remove ref_dynamic_nonweak added by accident
used pr11138-1.map to build libpr14862.so by accident and pr14862.map
should be used instead. The difference is
pr11138-1.map:
VERS_1 {
global: bar; foo;
local: *;
};
vs
pr14862.map:
VERS_1 {
global: bar;
local: *;
};
Since only "bar" is used, it didn't cause test failure. Use pr14862.map
to build libpr14862.so as intended.
PR ld/14862
* ld-elf/shared.exp: Replace pr11138-1.map with pr14862.map
when building libpr14862.so.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Add GPR and FPR symbolic register names to GAS for all ABI choices,
selecting the set of names based on the ABI being assembled for.
This extends the existing feature where the oldabi and newabi would
provide different symbolic GPR names to the assembler. Both EABIs and
o64 are now supported along with symbolic FPR names for all ABI choices.
Signed-off-by: Maximilian Ciric <max.ciric@gmail.com>
microblaze-linux.c is out of date compared to the other .c files in the
features directory. I think it's because it's missing from XMLTOC. Add
it there and run the "cfiles" target, causing the updates to
microblaze-linux.c.
I thought that we could get rid of regformats/microblaze-linux.dat,
since microblaze-linux is described with an XML target, but apparently
not, I don't really understand (or forget) how these things work.
Change-Id: Idaa55980b3bbdcc6597e9bf332d5824759ef9d0f
Approved-By: Tom Tromey <tom@tromey.com>
I spotted this call missing an argument.
For context, init_target_desc gained this osabi parameter in this
commit:
Author: Andrew Burgess <aburgess@redhat.com>
AuthorDate: Fri Oct 4 19:30:04 2024 +0100
Commit: Andrew Burgess <aburgess@redhat.com>
CommitDate: Tue Nov 12 12:51:36 2024 +0000
gdbserver: pass osabi to GDB in more target descriptions
This bug was present in GDB 16. I wonder if anybody uses this today.
Change-Id: Id5483be3efa0ca9d238d59af8abae94e8bdbd57c
Approved-By: Tom Tromey <tom@tromey.com>
The tix6x gdbserver port was modified to use target descriptions in
commit 506fe5f499 ("Change tic6x target descriptions"). The old
regformats .dat files were kept as a way to make sure the new target
descriptions matched the old register decsriptions. I think by now it's
not necessary to keep the .dat files.
I don't have a way to build-test this though.
Change-Id: Ia90b5ae6381234c6e95555201d3e65ed9be880ea
Approved-By: Tom Tromey <tom@tromey.com>
Replace some explicitly deleted copy constructor and copy assignment
operator with the DISABLE_COPY_AND_ASSIGN macro for consistency
with the rest of the codebase.
Change-Id: If3fe2c4d7b3cb4530eace86d589116f805c7656f
Approved-By: Tom Tromey <tom@tromey.com>
A user pointed out that if multiple breakpoints are set at the same
spot, in DAP mode, then changing the breakpoints won't reset all of
them.
The problem here is that the breakpoint map only stores a single
breakpoint, so if two breakpoints have the same key, only one will be
stored. Then, when breakpoints are changed, the "missing" breakpoint
will not be deleted.
The fix is to change the map to store a list of breakpoints.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33467
Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>
This renames the variable 'breakpoint_map' in DAP's breakpoint.py,
adding an underscore to make it clear that it is private to the
module.
Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>
The Pascal language is not case-sensitive, so implement the
appropriate language method. This fixes gdb.pascal failures with
-gw3.
I wasn't sure if -gw3 should be the default so I've left it as-is.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33617
Approved-By: Tom de Vries <tdevries@suse.de>
On i686-linux, with test-case gdb.rust/methods.exp I get:
...
(gdb) print x.take()
$5 = methods::HasMethods {value: 4}
(gdb) FAIL: $exp: print x.take()
...
The instructions for the function methods::HasMethods::take look like this:
...
00007b90 <_ZN7methods10HasMethods4take17hf373500ea3bd6e27E>:
7b90: 8b 44 24 04 mov 0x4(%esp),%eax
7b94: c3 ret
...
which is equivalent to what you get for:
...
$ cat test.c
int foo (int val) { return val; }
$ gcc test.c -O2 -S -o-
...
movl 4(%esp), %eax
ret
...
$
...
The inferior call mechanism however decides that this is a return_method_struct
function, and adds an implicit first parameter pointing to the return value
location. Then two things go wrong:
- the argument is written to a place where the code doesn't read from, and
- the return value is read from a place where the code doesn't write to.
AFAIU, both gdb and rustc are behaving correctly:
- there's no stable ABI and consequently rustc is at liberty to optimize this
function how it wants, and
- gdb cannot be expected to target an unstable ABI.
The solution is to mark the function for interoperability using 'extern "C"'.
Doing so causes a compilation warning:
...
warning: `extern` fn uses type `HasMethods`, which is not FFI-safe
--> gdb.rust/methods.rs:50:28
|
50 | pub extern "C" fn take(self) -> HasMethods {
| ^^^^ not FFI-safe
|
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute
to this struct
= note: this struct has unspecified layout
...
which we fix by using '#[repr(C)]'.
Likewise in gdb.rust/generics.exp.
Tested on i686-linux and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Commit bd1ea41b84 introduced the R_390_TLS_GOTIE20 relocation, but
missed to update a comment that mentions the related R_390_TLS_GOTIE12
relocation.
bfd/
* elf32-s390.c (allocate_dynrelocs): Mention GOTIE20 relocation
in TLS related comment.
* elf64-s390.c (allocate_dynrelocs): Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Commit 69fc87f180 introduced TLS support for s390 32-bit and 64-bit.
It defined GOT_TLS_IE_NLT in both elf32-s390.c and elf64-s390.c, but
erroneously assigned it the same value as GOT_TLS_IE in elf64-s390.c.
As a consequence the linker for s390 64-bit erroneously emitted an
orphaned GOT entry when performing TLS Initial Exec (IE) to Local
Exec (LE) transition optimization.
Correct the value of GOT_TLS_IE_NLT in elf64-s390.c. This causes the
liker to actually optimize away the GOT entry when performing IE to LE
transition. While at it add a comment that the suffix NLT denotes
"no literal (pool entry)".
Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.
bfd/
* elf32-s390.c (GOT_TLS_IE_NLT): Add comment that NLT denotes
no literal pool entry.
* elf64-s390.c (GOT_TLS_IE_NLT): Likewise. Correct value.
ld/testsuite/
* ld-s390/tlsbin_64.dd: Adjust expected test results.
* ld-s390/tlsbin_64.sd: Likewise.
Fixes: 69fc87f180
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Add check for sreldynrelro being NULL, introduced by commit 5474d94f03
("dynrelro section for read-only dynamic symbols copied into
executable") in elf32-s390.c function elf_s390_finish_dynamic_symbol,
also to its elf64-s390.c counterpart.
Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.
bfd/
* elf64-s390.c (elf_s390_finish_dynamic_symbol): Add
sreldynrelro check from elf32-s390.c.
Fixes: 5474d94f03 ("dynrelro section for read-only dynamic symbols copied into executable")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Commit fb798c50b2 added the R_390_PC24DBL relocation. Due to a copy
and paste error it messed up to increment the PC-relative relocation
count in elf64-s390.c function elf_s390_check_relocs (i.e. duplicate
check for R_390_PC16DBL).
Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.
bfd/
* elf64-s390.c (elf_s390_check_relocs): Increment PC-relative
relocation count for R_390_PC24DBL.
Fixes: fb798c50b2
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
They're solely used as hook functions (or helpers thereof), so aren't
intended to be invoked directly from outside the library. Add underscore
prefixes and make them hidden.
As non-private functions, they should come with full disambiguating
prefixes - add bfd_elf_ to both. Hence commit bf4128d0cc ("bfd/ELF:
mark internal NDS32 functions hidden") also wrongly added ATTRIBUTE_HIDDEN
to them.
As non-private functions, they should come with full disambiguating
prefixes - add bfd_elf_ to both. Hence commit 2903d813fc ("bfd/ELF: mark
internal LoongArch functions hidden") also wrongly added ATTRIBUTE_HIDDEN
to them.
While loongarch_get_uleb128_length() also falls in the same category,
having it live in libbfd, when outside of gas there's hardly any use to be
expected, isn't very useful. Drop the function altogether and simplify the
clearing of the ULEB128 in md_apply_fix().
For loongarch_larch_reloc_name_lookup() drop gas'es custom declaration;
the libbfd one ought to be used, for producer and consumer to "see" the
same one. Also drop ATTRIBUTE_UNUSED there, as that makes sense only for
parameters in function definitions.
This exposes an error on alpha-linux-gnuecoff where the start and end
syms are given the wrong storage class.
* testsuite/binutils-all/objcopy.exp (binary_symbol): Tighten
symbol type checking.
Fix those:
gdb/testsuite/gdb.base/gdb-index-many-types.py:17:18: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:26:42: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:29:16: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:31:19: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:33:16: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:33:51: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:47:17: E722 do not use bare 'except'
Change-Id: Iba1949a211af66e8dd1e6cb77a44845e5fa60c2e
This commit removes the attempted de-duplication of types when
building the gdb-index. This commit is the natural extension of this
earlier commit:
commit aef36dee93
Date: Sun Aug 13 14:08:06 2023 +0200
[gdb/symtab] Don't deduplicate variables in gdb-index
Which removed the de-duplication of variables. It is worth reading
the earlier commit as all the justifications for that patch also
apply to this one.
Currently, when building the gdb-index we sort the type entries,
moving declarations to the end of the entry list, and non-declarations
to the front. Then within each group, declarations, and
non-declarations, the index entries are sorted by CU offset.
We then emit the first entry for any given type name.
There are two problems with this.
First, a non-declaration entry could be a definition, but it could
also be a typedef. Now sure, a typedef is a type definition, but not
necessarily a useful one.
If we have a header file that contains:
typedef struct foo_t foo_t;
And a CU which makes use of 'foo_t', then the CU will include both a
typedef and a type declaration. The target of the typedef will be the
declaration. But notice, the CU will not include a type definition.
If we have two CUs, one which only sees the above typedef and
declaration, and another which sees the typedef and an actual type
definition, then the final list of entries for this type's name will
be:
1. A typedef entry that points at the declaration.
2. A typedef entry that points at the definition.
3. A definition.
4. A declaration.
Now (4) will get sorted to the end of the entry list. But the order
of (1), (2), and (3) will depend on the CU offset. If the CU which
containing the typedef and declaration has the smallest offset,
then (1) will be sorted to the front of the list of entries for this
type name. Due to the de-duplication code this means that only (1)
will be added to the gdb-index.
After GDB starts and parses the index, if a user references 'foo_t'
GDB will look in the index and find just (1). GDB loads the CU
containing (1) and finds both the typedef and the declaration. But
GDB does not find the full type definition. As a result GDB will
display 'foo_t' as an incomplete type.
This differs from the behaviour when no index is used. With no index
GDB expands the first CU containing 'foo_t', finds the typedef and
type declaration, decides that this is not good enough and carries on.
GDB will then expand the second CU and find the type's definition, GDB
now has a full understanding of the type, and can print the type
correctly.
We could solve this problem by marking typedefs as a distinct
sub-category of types, just as we do with declarations. Then we could
sort definitions to the front of the list, then typedefs, and finally,
declarations after that. This would, I think, mean that we always
prefer emitting a definition for a type, which would resolve this
first problem, or at least, it would resolve it well enough, but it
wouldn't fix the second problem.
The second problem is that the Python API and the 'info types' command
can be used to query all type symbols. As such, GDB needs to be able
to find all the CUs which contain a given type. Especially as it is
possible that a type might be defined differently within different
CUs.
NOTE: Obviously a program doing this (defining a type differently in
different CUs) would need to be mindful of the One Definition Rule,
but so long as the type doesn't escape outside of a single CU then
reusing a type name isn't, as I understand it, wrong. And even if
it is, the fact that it compiles, and could be a source of bugs,
means (in my opinion) that GDB should handle this case to enable
debugging of it.
Even something as simple as 'info types ....' relies on GDB being able
to find multiple entries for a given type in different CUs. If the
index only contains a single type entry, then this means GDB will see
different things depending on which CUs happen to have been expanded.
Given all of the above, I think that any attempt to remove type
entries from the gdb-index is unsafe and can result in GDB behaving
differently when using the gdb-index compared to using no index.
The solution is to remove the de-duplication code, which is what this
patch does.
Now that we no longer need to sort declarations to the end of the
entry list, I've removed all the code related to the special use of
GDB_INDEX_SYMBOL_KIND_UNUSED5 (which is how we marked declarations),
this cleans things up a little bit.
I've also renamed some of the functions away from minimize, now that
there's no minimization being done.
A problem was revealed by this change. When running the test
gdb.cp/stub-array-size.exp with the --target_board=cc-with-gdb-index,
I was seeing a failure using gcc 15.1.0.
This test has two CUs, and a type 'A'. The test description says:
Test size of arrays of stubbed types (structures where the full
definition is not immediately available).
Which I don't really understand given the test's source code. The
type 'A' is defined in a header, which is included in both CUs.
However, the test description does seem to be accurate; in one CU the
type looks like this:
<1><4a>: Abbrev Number: 8 (DW_TAG_structure_type)
<4b> DW_AT_name : A
<4d> DW_AT_declaration : 1
<4d> DW_AT_sibling : <0x6d>
<2><51>: Abbrev Number: 9 (DW_TAG_subprogram)
<52> DW_AT_external : 1
<52> DW_AT_name : ~A
<55> DW_AT_decl_file : 2
<56> DW_AT_decl_line : 20
<57> DW_AT_decl_column : 11
<58> DW_AT_linkage_name: (indirect string, offset: 0x103): _ZN1AD4Ev
<5c> DW_AT_virtuality : 1 (virtual)
<5d> DW_AT_containing_type: <0x4a>
<61> DW_AT_declaration : 1
<61> DW_AT_object_pointer: <0x66>
<65> DW_AT_inline : 0 (not inlined)
<3><66>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<67> DW_AT_type : <0x8c>
<6b> DW_AT_artificial : 1
<3><6b>: Abbrev Number: 0
<2><6c>: Abbrev Number: 0
while in the second CU, the type looks like this:
<1><178>: Abbrev Number: 4 (DW_TAG_structure_type)
<179> DW_AT_name : A
<17b> DW_AT_byte_size : 8
<17c> DW_AT_decl_file : 2
<17d> DW_AT_decl_line : 18
<17e> DW_AT_decl_column : 8
<17f> DW_AT_containing_type: <0x178>
<183> DW_AT_sibling : <0x1ac>
<2><187>: Abbrev Number: 5 (DW_TAG_member)
<188> DW_AT_name : (indirect string, offset: 0x19e): _vptr.A
<18c> DW_AT_type : <0x1be>
<190> DW_AT_data_member_location: 0
<191> DW_AT_artificial : 1
<2><191>: Abbrev Number: 6 (DW_TAG_subprogram)
<192> DW_AT_external : 1
<192> DW_AT_name : ~A
<195> DW_AT_decl_file : 1
<196> DW_AT_decl_line : 20
<197> DW_AT_decl_column : 1
<198> DW_AT_linkage_name: (indirect string, offset: 0x103): _ZN1AD4Ev
<19c> DW_AT_virtuality : 1 (virtual)
<19d> DW_AT_containing_type: <0x178>
<1a1> DW_AT_declaration : 1
<1a1> DW_AT_object_pointer: <0x1a5>
<3><1a5>: Abbrev Number: 7 (DW_TAG_formal_parameter)
<1a6> DW_AT_type : <0x1cd>
<1aa> DW_AT_artificial : 1
<3><1aa>: Abbrev Number: 0
<2><1ab>: Abbrev Number: 0
So, for reasons that I don't understand, the type, despite (as far as
I can see) having its full definition available, is recorded only as
declared in one CU.
The test then performs some actions that rely on 'sizeof(A)' and
expects GDB to correctly figure out the size. This requires GDB to
find, and expand the CU containing the real definition of 'A'.
Prior to this patch GDB would sort the two type entries for 'A',
placing the declaration second, and then record only one entry, the
definition. When it came to expansion there was only one thing to
expand, and this is the declaration we needed. It happens that in
this test the definition is in the second CU, that is, the CU with the
biggest offset. This means that, if all index entries were considered
equal, the definition entry would be second. However, currently, due
to the way GDB forces definitions to the front, the entry for the
second CU, the definition, is placed first in the index, and with
de-duplication, this is the only entry added to the index.
After this patch, both the declaration and the definition are placed
in the index, and as the declaration is in the CU at offset 0, the
declaration is added first to the index.
This should be fine. When looking for 'A' GDB should expand the CU
containing the declaration, see that all we have is a declaration, and
so continue, next expanding the definition, at which point we're done.
However, in read-gdb-index.c, in the function
mapped_gdb_index::build_name_components, there is a work around for
gold bug PR gold/15646. Ironically, the bug here is that gold was not
removing duplicate index entries, and it is noted that this has a
performance impact on GDB. A work around for this was added to GDB in
commit:
commit 8943b87476
Date: Tue Nov 12 09:43:17 2013 -0800
Work around gold/15646.
A test for this was added in:
commit 40d22035a7
Date: Tue May 26 11:35:32 2020 +0200
[gdb/testsuite] Add test-case gold-gdb-index.exp
And the fix was tweaked in commit:
commit f030440daa
Date: Thu May 28 17:26:22 2020 +0200
[gdb/symtab] Make gold index workaround more precise
The problem specifically called out in the bug report is that
namespaces can appear in multiple CUs, and that trying to complete
'ns::misspelled' would expand every CU containing namespace 'ns' due
to the duplicate 'ns' type symbols.
The work around that was added in 8943b87476 was to ignore
duplicate global symbols when expanding entries from the index. In
commit f030440daa this work around was restricted to only ignore
duplicate type entries. This restriction was required to allow the
earlier de-duplication patch aef36dee93 to function correctly.
Now that I'm taking the work started in aef36dee93 to its
logical conclusion, and allowing duplicate type entries, the work
around of ignoring duplicate global type symbols is no longer needed,
and can be removed.
The associated test for this, added in 40d22035a7, is also
removed in this commit.
To be clear; the performance issue mentioned in PR gold/15646 is now
back again. But my claim is that gold was right all along to include
the duplicate index entries, and any performance hit we see as a
result, though unfortunate, is just a consequence of doing it right.
That doesn't mean there's not room for optimisation and improvement in
the future, though I don't have any immediate ideas, or plans in this
area. It's just we can't throw out a bunch of index entries that are
critical, and claim this as a performance optimisation.
I am seeing some failure with this patch when using the board file
dwarf5-fission-debug-types. These failures all have the error:
DWARF Error: wrong unit_type in unit header (is DW_UT_skeleton, should be DW_UT_type) [in module ....]
However, I ran the whole testsuite with this board, and this error
crops up often, so I don't think this is something specific to my
patch, so I'm choosing to ignore this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15646
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15035
Approved-By: Tom Tromey <tom@tromey.com>
Consider the C construct:
typedef struct foo
{
int a;
int b;
} foo;
GDB will see two types here, 'struct foo' and the typedef 'foo'.
However, if we use 'info types foo' we will see this:
File test.c:
18: struct foo;
At least that's what I see with current HEAD of master. However, it
is really just luck that we see the 'struct' here. See more below.
When searching for symbols matching 'foo' GDB ends up in the function
global_symbol_searcher::add_matching_symbols, where we consider all
possible matching symbols. This will include the 'struct foo' and the
typedef 'foo'. However, before a new symbols is added to the results,
we attempt to remove duplicates with this code:
/* Match, insert if not already in the results. */
symbol_search ss (block, sym);
if (result_set->find (ss) == result_set->end ())
result_set->insert (ss);
If a symbol is already present in result_set then it will not be added
a second time.
The symbol_search equality check is done using the function
symbol_search::compare_search_syms, this function does a number of
checks, but at the end, any two symbols that are in the same block
within the same file, with the same name, are considered the same,
even if the types of those symbols are different.
This makes sense in most cases, it usually wouldn't make sense to have
two symbols within a single block with different types. But the
'struct foo' and typedef 'foo' case is a bit of a strange one. Within
DWARF and GDB we consider both of these as just types. But in C
types and structure names live in different namespaces, and so we can
have both in the same block. I don't think that GDB should consider
these two as the same, especially if we consider something really
ill-advised like this:
struct foo
{
int a;
int b;
};
typedef int foo;
This is perfectly valid C code, 'struct foo' and the typedef 'foo' are
in different namespaces, and can be used within the same block. But
please, never write C code like this.
Given the above, I think, when asked about 'foo', GDB should, report
both 'struct foo' and the typedef 'foo'.
To do this I propose extending symbol_search::compare_search_syms such
that if two symbol_search objects are in the same block, within the
same file, and they have the same name, then if just one of them is a
typedef, the two objects will not be considered equal. The results
will be sorted by line number if the line numbers are different, or,
if the line numbers are the same, the non-typedef will be sorted
first. This means that for something like this:
typedef struct foo { int a; } foo;
We'll get an 'info types foo' result like:
File test.c:
18: struct foo;
18: typedef struct foo foo;
I mentioned earlier that it is really just luck that we see 'struct
foo'. I ran into this problem while working on another patch. When
testing with the 'debug-types' board file I was seeing the typedef
being reported rather than the struct. In "normal" DWARF given the
'typedef struct foo { ...} foo;' construct, the compiler will usually
emit the struct definition first, and then the typedef definition. So
when GDB parses the DWARF it sees the struct first. It is the typedef
that becomes the duplicate which is not added to the results list.
But with the 'debug-types' board the compiler moves the struct
definition out to the .debug_types section. And GDB now parses the CU
containing the typedef first, and then expands the structure
definition from the separate section afterwards. As a result, it is
the structure that is now considered the duplicate, and the typedef is
the result that gets reported.
I think this is yet another motivation for this patch. Changes like
this (the use of .debug_types section) shouldn't impact what results
GDB shows to the user.
There is an interesting update to the gdb.base/info-types.exp.tcl test
script. In this case the C results only needed to change to include
the typedef. The C++ results already included both the struct and the
typedef in the expected results. The reason for this is that C places
both the struct baz_t and the typedef for baz_t into the global block,
while C++ places the struct in the global block, and the typedef into
the static block. I have no idea why there's a difference in the
placement, but I'm choosing to believe the difference is correct. But
this explains why only the C results needed to change. If anything
this (I think) is yet another justification for this change; having C
not show the typedef in this case seems weird when the same source
code compiled as C++ does show the typedef.
Approved-By: Tom Tromey <tom@tromey.com>
With test-case gdb.base/nodebug.exp I run into:
...
gdb compile failed, gdb.base/nodebug.c: In function 'multf_noproto':
gdb.base/nodebug.c:63:1: warning: old-style function definition \
[-Wold-style-definition]
63 | multf_noproto (v1, v2)
| ^~~~~~~~~~~~~
...
Fix this using -std=c99.
Tested on x86_64-linux.
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
On x86_64-linux, with test-case gdb.rust/simple.exp I get:
...
(gdb) print sizeof(e)^M
$52 = 24^M
(gdb) PASS: $exp: print sizeof(e)
...
but on i686-linux I get instead:
...
(gdb) print sizeof(e)^M
$52 = 20^M
(gdb) FAIL: $exp: print sizeof(e)
...
The variable e for which we print the size:
...
let e = MoreComplicated::Two(73);
...
has type MoreComplicated which is defined like this:
...
pub struct HiBob {
pub field1: i32,
field2: u64,
}
...
enum MoreComplicated {
One,
Two(i32),
Three(HiBob),
Four{this: bool, is: u8, a: char, struct_: u64, variant: u32},
}
...
The answer to the question what the size of the enum should be seems to be
non-trivial [1][2], but AFAICT it doesn't seem to be illegal that the size can
differ between different platforms.
Fix this by accepting both 20 and 24 as valid size.
Tested on x86_64-linux and i686-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://doc.rust-lang.org/reference/types/enum.html
[2] https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation
This commit allows GDB to make use of the file set with the 'file'
command when starting a new inferior on an extended-remote target.
There are however some restrictions.
If the user has used 'set remote exec-file', then this setting is
always used in preference to the file set with the 'file' command.
Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
that the remote target has an executable set, then this will be used
in preference to the file set with the 'file' command; this preserves
GDB's existing behaviour. In effect, when GDB connects to the remote
target, the remote sets the 'remote exec-file' and this prevents GDB
from using the 'file' filename.
And, GDB can only use the file set with the 'file' command if it
believes that both GDB and the remote target will both be able to
access this file. This means that one of these is true:
+ the the remote_target::filesystem_is_local function returns
true (see the implementation of that function for details of when
this can happen). This means GDB and the remote target can see
the same file system, GDB can just use the current executable's
filename as is, or
+ the user has set the 'file' to something with a 'target:' prefix,
e.g. 'file target:/path/to/exec'. In this last case, GDB will use
the exec filename without the 'target:' prefix, this filename is,
by definition, something the remote target can see, or
+ the sysroot has been updated by the user and no longer contains a
'target:' prefix. In this case, if the 'file' filename is within
the sysroot, then it is assumed the remote will also be able to
see a file with the same filename. For example, if the sysroot is
'/aa/', and the current executable is '/aa/bb/cc', then GDB will
tell the remote to run '/bb/cc'. One common case here is when the
sysroot is set to the empty string, which is usually done when GDB
and the remote target can see the same filesystem, in this case
GDB will use the current executable's filename unmodified.
If one of these conditions is met, then GDB will use the current
executable's filename (with possible modifications as mentioned
above), when starting a new extended-remote inferior, in all other
cases, GDB will use the file name set with 'set remote exec-file'.
This change could be useful any time a user is running a remote target
on the same machine as GDB, but I am specifically thinking of the case
where GDB is using a tool other than gdbserver, e.g. valgrind, as this
saves one additional step that a user must remember. The current
steps to start valgrind with GDB, as given on the valgrind
website (https://valgrind.org/docs/manual/manual-core-adv.html) are:
$ gdb prog
(gdb) set remote exec-file prog
(gdb) set sysroot /
(gdb) target extended-remote | vgdb --multi --vargs -q
(gdb) start
With this GDB work, and once support for the qExecAndArgs packet is
added to valgrind, then the 'set remote exec-file' line can be dropped
from those instructions.
This commit also extends the 'show remote exec-file' command so that
GDB will display the automatic value that it plans to use. Here's an
example of the new output:
$ gdb -q /tmp/hello
Reading symbols from /tmp/hello...
(gdb) set sysroot
(gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
Remote debugging using | ./gdbserver/gdbserver --multi --once -
Remote debugging using stdio
(gdb) show remote exec-file
The remote exec-file is unset, using automatic value "/tmp/hello".
The last line shows the new output.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change the types to target_desc_up so it's not needed to `.release()`
them. This is similar to this review comment:
https: //inbox.sourceware.org/gdb-patches/87seeuak0z.fsf@tromey.com/
Change-Id: I45e0e77b00701aa979e8f7f15f397836b4e19849
Approved-By: Maciej W. Rozycki <macro@orcam.me.uk>
Tested-By: Maciej W. Rozycki <macro@orcam.me.uk>
A small tidy that allows other symbols or warnings to appear in nm
output, and works around the case problem of windows drive letters
by simply omitting the $srcdir match.
* testsuite/binutils-all/objcopy.exp (binary_symbol): Check
objcopy and nm return status. Don't repeat prune_warnings
already done in binutils_run. Match each symbol separately,
reporting which match failed on a failure. Don't match
$srcdir in implicit test.
With qemu supporting 64 bit now, add some code to determine the
register size of a hppa remote target.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Iffade4e02d758b9cb20c8f206e812bf3205518f7
On i686-linux (and likewise arm-linux), I run into:
...
(gdb) file str-chars^M
Reading symbols from str-chars...^M
warning: stabs debug information is not supported.^M
(No debugging symbols found in str-chars)^M
(gdb) delete breakpoints^M
...
Fix this by using fpc option -gw2.
Tested on i686-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR testsuite/33564
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33564
A review of an earlier version of this series pointed out some missing
_() invocations in symmisc.c. This fixes the ones I thought were
appropriate. In some spots I chose not to add them because the text
didn't seem like something that ought to be translated.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
While exploring a question I had about the DWARF indexer, I found I
wanted to see the CU index of each entry. This patch adds this
information.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I was looking at some "maint" output and noticed that symmisc.c could
apply styling in a few spots. This patch is the result.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
