Sections without SEC_HAS_CONTENTS avoid the file size checks, and of
course it doesn't make sense to read such as the contents are all
zero.
* som.c (som_set_reloc_info): Don't read sections without contents.
This fixes some holes found by fuzzers, and removes aborts that can be
triggered by user input to objdump. Abort should only be used within
bfd to show programming errors in bfd.
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Handle
NULL howto. Don't abort on stack errors or on unexpected relocs.
Show more bfd reloc status messages.
When compiling hello world and adding a v9 .gdb-index section:
...
$ gcc -g hello.c
$ gdb-add-index a.out
...
readelf shows it as:
...
Shortcut table:
Language of main: unknown: 0
Name of main: ^A
...
The documentation of gdb says about the "Name of main" that:
...
This value must be ignored if the value for the language of main is zero.
...
Implement this approach in display_gdb_index, such that we have instead:
...
Shortcut table:
Language of main: unknown: 0
Name of main: <unknown>
...
Tested on x86_64-linux.
Approved-By: Jan Beulich <jbeulich@suse.com>
The as and ld use _bfd_error_handler to output error messages when
checking relocation alignment and relocation overflow. However, the
abfd value passed by as to the function is NULL, resulting in an
internal error. The ld passes a non-null value to the function,
so it can output an error message normally.
First of all add f32_5[], allowing to eliminate the extra slot-is-NULL
code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[]
following the same concept of adding a %cs segment override prefix.
Also re-use patterns when possible and correct comments as applicable.
Similarly re-use testcase expectations as much as possible, where they
need touching anyway.
The two are distinct in opcodes/, distinguished precisely by CpuNOP
that's relevant in i386_generate_nops(), yet the function has the PPro
case label in the other group. Simply removing it revealed that
cpu_arch[] had a wrong entry for i686.
While there also add PROCESSOR_IAMCU to the respective comment.
Making GENERIC64 a special case was never correct; prior to the
generalization of ".arch .no*" to cover all ISA extensions other
processor families supporting long NOPs should have been covered as
well. When introducing ".arch .nonops" (among others) it wasn't
apparent that a hidden implication of .cpunop not being possible to
separately turn off existed here. Seeing that the two large case label
blocks in the 2nd switch() already had identical behavior, simply
collapse all of the (useful) case labels into a single "default" one.
Since we don't key the NOP selection to user-controlled properties, we
may not use i386 features; otherwise we would violate a possible .arch
directive restricting ISA to pre-386.
Except for the shared 1- and 2-byte cases, the LEA uses corrupt %rsi
(by zero-extending %esi to %rsi). Introduce separate 64-bit patterns
which keep %rsi intact.
What matters is what was in effect at the time the original directive
was issued. Later changes to global state (bitness or ISA) must not
affect what code is generated.
The recorded value, and not the global variable, will want using in
TC_FRAG_INIT(). The so far file scope variable therefore needs to become
external, to be accessible there.
The help says that <reserve> and <commit> should be separated by a ","
but the implementation is checking for ".". Having two numbers being
separated by a "." could be confusing, thus adjust the implementation to
match the help syntax.
binutils/ChangeLog:
* objcopy.c (copy_main): Set separator to "," between <reserve>
and <commit> for --heap and --stack.
* doc/binutils.texi: Add <commit> for --heap and --stack.
I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't
match that committed to bfd-in2.h, and was just going to regen
bfd-in2.h but then decided to do something about the silly formatting
of these comments in bfd-in2.h. eg. the BFD_RELOC_MICROBLAZE_32_NONE
comment:
-/* This is a 32 bit reloc that stores the 32 bit pc relative
-value in two words (with an imm instruction).No relocation is
-done here - only used for relaxing */
+ /* This is a 32 bit reloc that stores the 32 bit pc relative value in
+ two words (with an imm instruction). No relocation is done here -
+ only used for relaxing. */
BFD_RELOC_MICROBLAZE_32_NONE,
You'll notice how the second and third line of the original comment
aren't indented properly relative to the first line, and the whole
comment needs to be indented to match the code.
I've also edited reloc.c ENUMDOC paragraphs. Some of these had excess
indentation, presumably in an attempt to properly indent bfd-in2.h
comments but that fails due to chew.c removing leading whitespace
early by skip_white_and_stars. COMMENT was used in reloc.c to add
extra blank lines in bfd-in2.h. I've removed them too as I don't
think they add anything to readability of that file. (Perhaps more
usefully, they also add blank lines to libbfd.h separating relocs for
one target from others, but this isn't done consistently.)
* doc/chew.c (drop, idrop): Move earlier.
(strip_trailing_newlines): Check index before accessing array,
not after.
(wrap_comment): New function.
(main): Add "wrap_comment" intrinsic.
* doc/proto.str (ENUMDOC): Use wrap_comment.
(make_enum_header, ENDSENUM): Put start and end braces on
separate lines.
* reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
When printing a value, I think the history reference -- the "$1" in
the output -- should be styled using the "variable" style. This patch
implements this.
Commit 8971d2788e ("gdb: link so_list using intrusive_list") introduced
a bug in clear_solib. Instead of passing an `so_list *` to
remove_target_sections, it passed an `so_list **`. This was not caught
by the compiler, because remove_target_sections takes a `void *` as the
"owner", so you can pass it any pointer and it won't complain.
This happened because I previously had a patch to change the type of the
disposer parameter to be a reference rather than a pointer, so had to
change `so` to `&so`. When dropping that patch, I forgot to revert this
bit and / or it got re-introduced when handling subsequent merge
conflicts. And I didn't properly retest.
Fix that, but try to make things less error prone. Add a union to
represent the possible owner kinds for a target_section. Trying to pass
a pointer to another type than those will not compile.
Change-Id: I600cab5ea0408ccc5638467b760768161ca3036c
Currently when gdb asks the source-highlight library to highlight a file, it
tells it what language file to use.
For instance, if gdb learns from the debug info that the file is language_c,
the language file "c.lang" is used. This mapping is hardcoded in
get_language_name.
However, if gdb doesn't know what language file to use, it falls back to using
python pygments, and in absence of that, unhighlighted source text.
In the case of python pygments, it autodetects which language to use based on
the file name.
Add the same capability when using the source-highlight library.
Tested on x86_64-linux.
Verified that it works by:
- making get_language_name return nullptr for language_c, and
- checking that source-highlight still manages to highlight a hello world.
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
dwarf2/read.h includes cooked-index.h, but it doesn't need to. This
patch removes the inclusion from this header, and adds one to
index-write.c to make up for the absence.
This patch makes a cosmetic change to the reloc_weaksym.s
by making the bneid instruction all lower case like all of
the other instructions in the example.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
The fixes applied a few years ago to resolve confusions between parent and
child dicts at lookup time also apply in various forms to creation. In
general, if you have a type in a parent dict ctf_imported into a child and
you do something to it, and the parent dict is writable (created via
ctf_create, not opened via ctf_open*) it should work just the same to make
changes to that type via a child dict as it does to make the change
to the parent dict directly -- and nothing you're prohibited from doing
to the parent dict when done directly should be allowed just because
you're doing it via a child.
Specifically, the following don't work when doing things from the child, but
should:
- adding a member of a type in the parent to a struct or union in the
parent via ctf_add_member or ctf_add_member_offset: this yields
ECTF_BADID
- adding a member of a type in the parent to a struct or union in the
parent via ctf_add_member_encoded: this dumps core (!).
- adding an enumerand to an enumerator in the parent: this yields
ECTF_BADID
- setting the properties of an array in the parent via ctf_set_array;
this yields ECTF_BADID
Relatedly, some things work when doing things via a child that should fail,
yielding a CTF dictionary with invalid content (readable, but meaningless):
in particular, you can add a child type to a struct in the parent via
any of the ctf_add_member* family and nothing complains at all, even though
you should never be able to add references to children to parents (since any
given parent can be associated with many different children).
A family of tests is added to check each of these cases independently, since
some can result in coredumps and it would be nice to test the other cases
even if some dump core. They use a common library to do all the actual
work. The set of affected API calls was determined by code inspection
(auditing all calls to ctf_dtd_lookup): it's possible that I missed a few,
but I doubt it, since other cases use ctf_lookup* functions, which already
climb to the parent where appropriate.
libctf/ChangeLog:
PR libctf/30985
* ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary.
(ctf_set_array): Likewise. Report errors on the child; require
both parent and child to be writable.
(ctf_add_enumerator): Likewise.
(ctf_add_member_offset): Likewise. Prohibit addition of child types
to structs in the parent.
(ctf_add_member_encoded): Do not dereference a NULL dtd: report
ECTF_BADID instead.
* ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the
dict if addition of a string ref fails.
* testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library.
* testsuite/libctf-writable/parent-child-dtd-enum.*: New test.
* testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test.
* testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test.
* testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test.
* testsuite/libctf-writable/parent-child-dtd-set-array.*: New test.
* testsuite/libctf-writable/parent-child-dtd-struct.*: New test.
* testsuite/libctf-writable/parent-child-dtd-union.*: New test.
This patch adds the R_MICROBLAZE_32_NONE relocation type.
This is a 32-bit reloc that stores the 32-bit pc relative
value in two words (with an imm instruction).
Add test case to gas test suite.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
I noticed a few more style issues in commit 8b9c08edda ("[gdb/symtab] Add
name_of_main and language_of_main to the DWARF index"), after checking it
with gcc's check_GNU_style.{sh,py}.
Fix these.
Build on x86_64-linux.
There is currently a bug in the bit masking for the barrel shift
instructions because the bit mask is not including all of the
register bits which must be zero. With this patch, the disassembler
can be sure that the 32-bit value is indeed a barrel shift instruction
and not a data value in memory.
This fix can be verified by assembling and disassembling the following:
.text
.long 0x65005f5f
With this patch, the bug is fixed, and the objdump will know that
0x65005f5f is not a barrel shift instruction.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
The recent change to record the DWARF language in the per-CU data
yielded a race warning in my testing:
ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit
This patch fixes the bug by applying the same style of fix that was
done for the ordinary (gdb) language.
I wonder if this code could be improved. Requiring an atomic for the
language in particular seems unfortunate, as it is often consulted
during index finalization. However, I haven't investigated this.
Regression tested on x86-64 Fedora 38.
Reviewed-by: Tom de Vries <tdevries@suse.de>
Fixes:
CXX solib-target.o
/home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type
57 | static lm_info_vector
| ^~~~~~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’:
/home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope
244 | = solib_target_parse_libraries (library_document->data ());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Ib477d3343b401017d79729118242143bc95f24b2
Now that so_list lists are implemented using intrusive_list, it doesn't
really make sense for the element type to be named "_list". Rename to
just `struct shobj` (`struct so` was deemed to be not greppable enough).
Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Remove this function, replace it with deleting the so_list in callers.
Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
I think this `so.clear ()` call is not useful.
- so_list::clear deletes some things that now get automatically deleted
when the so_list gets deleted right after in free_so.
- so_list::clear resets some scalar fields of so_list, which we don't
really care about since the so_list gets deleted right after.
- so_list::clear calls target_so_ops::clear_so, of which there is a
single implementation, svr4_clear_so. That implementation just
resets a field in lm_info_svr4, which we don't care about, as it will
get deleted when the so_list gets deleted right after.
Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Replace the hand-made linked list implementation with intrusive_list,
simplying management of list items.
Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Change these two fields, simplifying memory management and copying.
Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically
manage the reference.
Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Make the field a vector directly, instead of a pointer to a vector.
This was needed when so_list had to be a trivial type, which is not the
case anymore.
Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Remove this typedef. I think that hiding the real type (std::vector)
behind a typedef just hinders readability.
Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
... just because it seems to make sense to do so.
Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Make it a unique_ptr, so it gets automatically deleted when the so_list
is deleted.
Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
I think this typedef hinders readability. First, it's not well named
(it's not clear it contains lm_info_target objects). And hiding the
fact that it contains unique pointers is not very useful either. I was
looking at the code in solib_target_current_sos where the unique
pointers get moved from the vector, and it wasn't obvious at all what
the source of the move was.
Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Same rationale as the previous patch, but for solib-rocm.
- Introduce rocm_so, which is a name a unique_name (see comment in
rocm_update_solib_list for that) and a unique_ptr to the
lm_info_svr4.
- Change the internal lists from so_list lists to vectors of rocm_so.
- Remove rocm_free_solib_list, as everything is automatic now.
- Replace rocm_solib_copy_list with so_list_from_rocm_sos.
Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
