There's no reason to limit this to just ELF. TI C30 and Z8k don't encode
section alignment in the section entries though (which can't be quite
right, or there would need to be another means by which to express
alignment needs), so --set-section-alignment simply has no effect there.
PR binutils/32732
The --set-section-alignment option is what ought to be used on object
files; --section-alignment should be affecting PE binaries only, and
only the value stored in the header. Sections don't individually have
alignment recorded there; see 6f8f6017a0c4 ("PR27567, Linking PE files
adds alignment section flags to executables").
Undo the core part of 121a3f4b4f4a ("Update objcopy's
--section-alignment option so that it sets the alignment flag on..."),
which includes removing the testcase again, while leaving all secondary
changes in place. (Note that the testcase did fail anyway for
i?86-interix, with objdump saying "option -P/--private not supported by
this file".)
With it only being the tail of the name which wants checking, using
lbasename() isn't helpful. Mirror what objcopy.c:main() does to ar.c,
merely chaning the plain int of the local variable to size_t.
The output file could be created before the input is gathered by tail,
erasing the later before it's being proceeded.
This happened on rare cases when performing remote tests on
Ubuntu 24.04.
Up to this point, no mention of RISC-V-specific disassembler options was
mentioned in binutils documentation. This patch includes description for
all of the currently supported options.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
Turns out the return value of parse_loongarch_dis_option acts as an
error code, and previously the function always signified failure with
a non-zero return value, making only the first disassembly option get
to take effect.
Fix by adding the missing `return 0`'s to the two success code paths.
Signed-off-by: WANG Xuerui <git@xen0n.name>
Section and file alignment are supposed to remain unaltered when PE
binaries are stripped. While this is the case when they're strip-ed
individually, passing multiple such files to strip would reset the
two values to their defaults in all but the first of those binaries.
Compilers may split functions, e.g. into a "hot" and "cold" part, or
they may emit special case instantiations (e.g. as a result of IPA). It
can be helpful to be able to disassemble all of the parts or clones in
one go. Permit using "--disassemble=" multiple times.
... when only their symbol was requested for disassembly. Addressing the
respective FIXME is as easy as coverting the "else" there to an if()
with the opposite condition, thus accounting for the disabling the
original if() may have effected.
Since commit ad6dde5aaae ("gdb/dwarf: write offset to parent entry for
DW_IDX_parent"), gdb now emits a .debug_names where the DW_IDX_parent
attribute refers to the parent entry's offset -- previously, due to
some confusion in the standard, gdb used the index of the parent's
name table entry.
This patch changes the .debug_names display code to display each
entry's offset. This makes it easy to refer from a DW_IDX_parent to
the correct entry.
The new output looks like this:
[...]
Symbol table:
[ 1] circular1: <0><1> DW_TAG_module DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x19> DW_IDX_GNU_language=19
[...]
[ 6] found: <0x28><2> DW_TAG_subprogram DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x38> DW_IDX_GNU_language=19 DW_IDX_parent=<0x0>
Here you can see that DW_IDX_parent=0 refers to "circular1: <0>".
This fixes a deficiency in commit 660df28acfa1, which should have used
the same logic as that in sym_ok. Ideally both places would not
compare section names, but it can be a little tricky to match a
section in the real object file with a section in a debug file.
Extend commit 39f0547e554d to use section name, vma and size.
* objcopy (is_same_section): New function.
(compare_symbols, sym_ok): Use it here.
read_coff_rsrc makes one check on object file contents, the existence
of a .rsrc section. It doesn't check that the file is PE but blindly
accesses bfd pe_data. Fix that by adding the necessary checks.
Also, the "resources nest too deep" error isn't an overrun, ie. the
"address out of bounds" message isn't correct. Fix that too.
ctf_archive_next returns an opened dict, which must be closed by the caller.
Thanks to Alan Modra for spotting this.
binutils/
* objdump.c (dump_ctf): Close dict.
* readelf.c (dump_section_as_ctf): Likewise.
<memory.h> is not needed and not standardized and is just an alias for
<string.h>.
<sys/param.h> is not needed and not standardized and contains a kitchen
sink of various unportable definitions not agreed upon and best done
manually or through other headers.
These fixes are needed to compile binutils on Sortix and other operating
systems with a strict POSIX.1-2024 libc without obsolete features.
Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org>
After I found his email bouncing, Stan, via private communication which
Nick helped with, has indicated that - having retired - he won't any
longer fulfill the maintainer role here.
Today I learned that, at least on my system (Fedora 40), the printf
"%#x" format will produce "0" rather than "0x0" when given 0 as an
argument.
This causes dwarf-mode.el to not correctly fontify the very first
"Compilation Unit" line it sees.
This patch adapts dwarf-mode.el. As always, this patch bumps the
version number for easier installation.
I am checking this in.
It is possible with fuzzed files to have num_debug_info_entries zero
after allocating space for debug_information, leading to multiple
allocations.
* dwarf.c (process_debug_info): Don't test num_debug_info_entries
to determine whether debug_information has been allocated,
test alloc_num_debug_info_entries.
dlltool copies strings with strdup all over the place, seeming to take
the attitude that anything might be modified. That leads to lots of
memory leaks. Fixing the leaks by removing the strdup calls of course
means you need to take good care that strings *aren't* modified. This
isn't as easy as it sounds due to functions like xlate that have
const char* params but then manage to modify the strings. I've fixed
xlate, but if I've missed something somewhere then this patch likely
will break dlltool. Testsuite coverage of dlltool isn't good.
The leaks in defparse.y are small. It also is a little work to verify
that all the strings I'm freeing in defparse.y are in fact malloc'd,
which is no doubt why the leaks are there.
Using bfd_xalloc in make_one_lib_file and functions called from there
results in memory being freed automatically at the bfd_close in
make_one_lib_file, without any fuss.
The patch also makes use of xasprintf to replace xmalloc followed by
sprintf.
* defparse.y (opt_name2): Free incoming ID strings after
adding prefix/suffix.
* dlltool.c (struct ifunct): Constify char* fields.
(struct iheadt, struct dlist): Likewise.
(set_dll_name_from_def, def_heapsize, def_stacksize),
(def_section, assemble_file): Use xasprintf.
(def_name, def_library): Free dll_name and name.
(def_description, new_directove): Don't strdup incoming args.
(append_import): Likewise.
(def_import): Free module after appending dllext.
(run): Free temp_base.
(scan_filtered_symbols): Don't segfault on NULL strchr return.
Remove unnecessary strdup.
(scan_drectve_symbols): Likewise. Constify pointers.
Use bfd_malloc_and_get_section. Use xmemdup.
(add_excludes): Use xasprintf and xstrdup.
(gen_exp_file): Free xlate return. Constify pointer to suit
struct changes. Free copy.
(xlate): Always copy arg. Use xasprintf and xstrdup.
(make_imp_label): Add bfd arg. Use bfd_xalloc.
(gen_lib_file): Adjust to suit.
(make_one_lib_file): Likewise. Use bfd_xalloc for section data
and relocs. Simplify code calling xlate, and free xlate return.
(dll_name_list_free_contents): Flatten recursion.
(mangle_defs): Free d_export_vec.
(main): Formatting. Use xasprintf.
* resres.c (write_res_id): Free section data.
This allows you to specify a run_dump_test warning that may or may not
be present using
warning: (warning_text_goes_here)?
ie. the regexp matches an empty string.
There's always someone pushing the boundaries.
PR 32560
* objdump.c (MAX_INSN_WIDTH): Define.
(insn_width): Make it an unsigned long.
(disassemble_bytes): Use MAX_INSN_WIDTH to size buffer.
(main <OPTION_INSN_WIDTH>): Restrict size of insn_width.
The GNU_PROPERTY_MEMORY_SEAL gnu property is a way to mark binaries
to be memory sealed by the loader, to avoid further changes of
PT_LOAD segments (such as unmapping or change permission flags).
This is done along with Linux kernel (the mseal syscall [1]), and
C runtime supports to instruct the kernel on the correct time during
program startup (for instance, after RELRO handling). This support
is added along the glibc support to handle the new gnu property [2].
This is a opt-in security features, like other security hardening
ones like NX-stack or RELRO.
The new property is ignored if present on ET_REL objects, and only
added on ET_EXEC/ET_DYN if the linker option is used. A gnu property
is used instead of DT_FLAGS_1 flag to allow memory sealing to work
with ET_EXEC without PT_DYNAMIC support (at least on glibc some ports
still do no support static-pie).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8be7258aad44b5e25977a98db136f677fa6f4370
[2] https://sourceware.org/pipermail/libc-alpha/2024-September/160291.html
Change-Id: Id47fadabecd24be0e83cff45653f7ce9a900ecf4
This patch adds a new CFI directive (cfi_negate_ra_state_with_pc) which
set an additional bit in the RA state to inform that RA was signed with
SP but also PC as an additional diversifier.
RA state | Description
0b00 | Return address not signed (default if no cfi_negate_ra_state*)
0b01 | Return address signed with SP (cfi_negate_ra_state)
0b10 | Invalid state
0b11 | Return address signed with SP+PC (cfi_negate_ra_state_with_pc)
Approved-by: Indu Bhagat <indu.bhagat@oracle.com>
Approved-by: Jan Beulich <jbeulich@suse.com>
