| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Seen when running ld-loongarch-elf/tlsdesc-dso test.
elfxx-loongarch.c:1844:32: runtime error: index 125 out of bounds for
type 'loongarch_reloc_howto_type [124]'
So either the loongarch_howto_table needs three more
LOONGARCH_EMPTY_HOWTO entries, or loongarch_elf_rtype_to_howto should
be testing for r_type < ARRAY_SIZE (loongarch_howto_table). I figure
it's worth wasting a little more space to get faster lookup.
* elfxx-loongarch.c (loongarch_howto_table): Add
LOONGARCH_EMPTY_HOWTO entries for 121..123.
(loongarch_elf_rtype_to_howto): Don't support slow lookup.
Assert exact table size and r_type indexing. Omit return cast.
(loongarch_reloc_name_lookup): Omit assertion and return cast.
(loongarch_reloc_type_lookup): Likewise.
|
|
Fix the ENOTDIR rmdir too.
PR 31191
* objcopy.c (copy_archive): Localise uses of "l". Remove
const from name_list.name. Unlink output element on bfd_close
error, and NULL list->name to indicate file is removed. Adjust
cleanup to prevent rmdir on non-existent file.
|
|
Since newlib allows people to opt-in to extra errno names, pull them
into our table too. The values don't conflict with each other -- the
newlib names & values are distinct from newlib's Linux compatibility.
|
|
|
|
|
|
|
|
|
|
The pcalau12i + addi.d of TLS LD/GD/DESC relax to pcaddi.
Relaxation is only performed when the TLS model transition is not possible.
|
|
Transitions between DESC->IE/LE and IE->LE are supported now.
1. For DESC -> LE:
pcalau12i $a0,%desc_pc_hi20(var) => lu12i.w $a0,%le_hi20(var)
addi.d $a0,$a0,%desc_pc_lo12(var) => ori $a0,$a0,%le_lo12(var)
ld.d $a1,$a0,%desc_ld(var) => NOP
jirl $ra,$a1,%desc_call(var) => NOP
add.d $a0,$a0,$tp
2. For DESC -> IE:
pcalau12i $a0,%desc_pc_hi20(var) => pcalau12i $a0,%ie_pc_hi20(var)
addi.d $a0,$a0,%desc_pc_lo12(var) => ld.d $a0,$a0,%ie_pc_lo12(var)
ld.d $a1,$a0,%desc_ld(var) => NOP
jirl $ra,$a1,%desc_call(var) => NOP
add.d $a0,$a0,$tp
3. For IE -> LE:
pcalau12i $a0,%ie_pc_hi20(var) => lu12i.w $a0,%le_hi20(var)
ld.d $a0,$a0,%ie_pc_lo12(var) => ori $a0,$a0,%le_lo12(var)
add.d $a0,$a0,$tp
4. When a tls variable is accessed using both DESC and IE, DESC transitions
to IE and uses the same GOT entry as IE.
|
|
1.The linker for each DESC generates a R_LARCH_TLS_DESC64 dynamic
relocation, which relocation is placed at .rela.dyn.
TLSDESC always allocates two GOT slots and one dynamic relocation
space to TLSDESC.
2. When using multiple ways to access the same TLS variable, a
maximum of 5 GOT slots are used. For example, using GD, TLSDESC,
and IE to access the same TLS variable, GD always uses the first
two of the five GOT, TLSDESC uses the third and fourth, and IE
uses the last.
|
|
The normal DESC instruction sequence is:
pcalau12i $a0,%desc_pc_hi20(var) #R_LARCH_TLS_DESC_PC_HI20
addi.d $a0,$a0,%desc_pc_lo12(var) #R_LARCH_TLS_DESC_PC_LO12
ld.d $ra,$a0,%desc_ld(var) #R_LARCH_TLS_DESC_LD
jirl $ra,$ra,%desc_call(var) #R_LARCH_TLS_DESC_CALL
add.d $a0,$a0,$tp
|
|
|
|
This fixes the buffer overflow added in commit 22b78fad28, and a few
other problems.
* loongarch-coder.c (loongarch_split_args_by_comma): Don't
overflow buffer when args == "". Don't remove unbalanced
quotes. Don't trim last arg if max number of args exceeded.
|
|
Some spots loop on the frame chain to find the first next non-inline
frame, and pass that as the "next frame" to
value::allocate_register_lazy / value::allocate_register. This is
necessary if the value is used in the process of computing the id of
"this frame". If the frame next to "this frame" is inlined into "this
frame", then you that next frame won't have a computed id yet. You have
to go past that to find the next non-inline frame, which will have a
computed id.
In other cases, it's fine to store the id of an inline frame as the
"next frame id" in a register struct value. When trying to unwind a
register from it, it will just call inline_frame_prev_register, which
will forward the request to the next next frame, until we hit the next
physical frame.
I think it would make things simpler to just never store the id of an
inline frame as the next frame id of register struct values, and go with
the first next non-inline frame directly. This way, we don't have to
wonder which code paths have to skip inline frames when creating
register values and which don't.
So, change value::allocate_register_lazy to do that work, and remove the
loops for the callers that did it.
Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310
|
|
Remove VALUE_REGNUM, replace it with a method on struct value. Set
`m_location.reg.regnum` directly from value::allocate_register_lazy,
which is fine because allocate_register_lazy is a static creation
function for struct value.
Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d
|
|
Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value. Set
`m_location.reg.next_frame_id` directly from value::allocate_register_lazy,
which is fine because allocate_register_lazy is a static creation
function for struct value.
Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6
|
|
As explained in the comment removed by the previous commit "gdb: pass
non-nullptr frame to gdbarch_value_from_register in
address_from_register", address_from_register copies some implementation
bits from value_from_register:
/* This routine may be called during early unwinding, at a time
where the ID of FRAME is not yet known. Calling value_from_register
would therefore abort in get_frame_id. However, since we only need
a temporary value that is never used as lvalue, we actually do not
really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement
the core of value_from_register, but use the null_frame_id. */
This is no longer relevant, since we now create a value with a valid next
frame id, so change address_from_register to use value_from_register.
Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43
|
|
By now, all register struct values should have a valid next frame id
(assuming they are created using value::allocate_register or
value::allocate_register_lazy), so there should be no need to pass a
frame alongside the value to read_frame_register_value. Remove the
frame parameter and adjust read_frame_register_value accordingly.
While at it, make read_frame_register_value static, it's only used in
findvar.c.
Change-Id: I118959ef8c628499297c67810916e8ba9934bfac
|
|
value::allocate_register_lazy
Some places that create register struct values don't use register_type
to obtain the value type. This prevents them from using the current
version of value::allocate_register. One spot (value_of_register_lazy)
also creates a lazy register value.
Add a value::allocate_register_lazy method. Add some type parameters
to value::allocate_register and value::allocate_register_lazy, to let
the caller specify the type to use for the value. The parameters
default to nullptr, in which case we use register_type to obtain the
type.
Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec
|
|
address_from_register
address_from_register used to pass null_frame_id to
gdbarch_value_from_register as "this frame"'s id, because it's possible
for it to be called during unwind, when "this frame"'s id is not yet
known. This create an oddity where those register struct values are
created without a valid next frame id. I would much prefer for things
to be consistent and have all register struct values to have a valid
next frame id.
Since gdbarch_value_from_register takes a frame_info_ptr now, rather
than a frame_id, we can pass down "this frame", even if it doesn't have
a valid id. gdbarch_value_from_register implementations can obtain the
next frame from it.
However, it's possible for the "this frame"'s next frame to be an
inline frame, inlined in "this frame", in which case that next frame's
id is also not known. So, loop until we get to the next non-inline
frame (which is actually the frame where registers for "this frame" are
unwound from). This is the same thing that we do in
value_of_register_lazy, for the same reason. A later patch will factor
out this "while next frame is inline" loop to apply it to all register
struct values, so this is somewhat temporary.
Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
|
|
Pass a frame_info_ptr rather than a frame_id. This avoids having to do
a frame lookup on the callee side, when we can just pass the frame down
directly.
I think this fixes a bug in rs6000-tdep.c where the id of the wrong
frame was set to `VALUE_NEXT_FRAME_ID (v)`.
Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565
|
|
I don't think that setting the next frame id is needed there, all code
paths in cooked_read_value do set it properly, AFAIK.
Change-Id: Idb9d9e6f89c2c95c5ebfeec2a63fde89ed84cf3d
|
|
|
|
Since this function never returns, mark it as such to fix some unused
variable warnings in error code paths.
For example, cris triggers:
sim/cris/semcrisv10f-switch.c:3558:11: error:
variable 'tmp_newval' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
Even though it has an "else" path that calls this error function.
|
|
Integrate some changes from upstream cgen that tightened up the
generated output. Shouldn't be any functional changes here.
|
|
Since these insns don't do anything and are effectively ignored,
return early to avoid doing any common processing at the end as
that requires initializing variables like "res" with something.
|
|
The plds Dz,MACL insn stores the Dz bit into MACL. The current code
was storing the "res" variable into Dz and then into MACL, but not
setting "res" to anything. Delete that logic and make it match the
existing plds Dz,MACH insn.
|
|
|
|
The -Wshadow=local is too new for some compilers, so move it to a var
that we test at configure time.
|
|
ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl.
Fixed by declaring these types for linux-musl.
2023-12-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30779
PR gprofng/29593
* common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl.
* libcollector/unwind.c: Define __u64 for linux-musl.
* src/util.h: Define dbe_stat_t.
* src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64".
* src/Dbe.cc: Likewise.
* src/DbeFile.cc: Likewise.
* src/DbeFile.h: Likewise.
* src/DbeSession.cc: Likewise.
* src/Experiment.cc: Likewise.
* src/checks.cc: Likewise.
* src/util.cc: Likewise.
|
|
Rename the var to avoid shadowing & clobbering the higher context.
|
|
Inline the one usage of sd in these macros to avoid possible shadowing.
|
|
Use a local name in the macro to avoid shadowing wherever it's used.
|
|
Delete redundant decls when the existing scope has the same var and
type available for use.
|
|
Delete redundant decls when the existing scope has the same var and
type available for use.
|
|
These decoders declare a lot of common variables for use by substeps,
and then shadows a few because of how the opc generator is implemented.
Easiest way around it is to rename the per-substep vars as needed as
anything more would require substantial changes to the opc logic.
|
|
Delete redundant decls.
|
|
Delete conflicting decls when the existing scope has vars of the same
name & type for this exact use.
|
|
Delete redundant decls, and rename conflicting vars.
|
|
Rename shadowed vars with different types to avoid confusion.
|
|
The mloop files include CGEN generated switch files which have some
nested assignments that expand into repeated shadowed variables.
Fixing this looks fairly non-trivial as it appears to be interplay
between the common CGEN code and how this particular set of cris
insns are defined. Disable the warning instead.
In file included from sim/cris/mloop.in:286:
sim/cris/semcrisv10f-switch.c: In function ‘crisv10f_engine_run_full’:
sim/cris/semcrisv10f-switch.c:12383:8: error: declaration of ‘opval’ shadows a previous local [-Werror=shadow=local]
12383 | SI opval = tmp_addr;
| ^~~~~
sim/cris/semcrisv10f-switch.c:12371:9: note: shadowed declaration is here
12371 | USI opval = ({ SI tmp_addr;
| ^~~~~
And the code looks like:
USI opval = ({
...
{
SI opval = tmp_addr;
...
}
...
});
Since the CGEN code treats "opval" as an internal variable that the cpu
definitions don't have direct access to, the likelihood of this being a
real bug is low, so leave it be. The warning is suppressed for more code
that is hand written (e.g. the mloop logic), but disabling for the entire
file is the easiest way to suppress while keeping it on everywhere else in
the sim.
|
|
Delete redundant local decls.
|
|
Rename shadowed vars with different types, and delete redundant decls.
|
|
Rename the shadowed var to avoid confusion with the function argument
as to which address this code is using.
|
|
Remove duplicate nested variable declarations, rename some to avoid
confusion when the type is different or the original value should be
retained, and fix some weirdness with nested enums in structs.
|
|
These functions have local vars named "val" of type float, and
then create nested vars named "val" of type double. This is a
bit confusing and causes build time warnings.
|
|
|
|
This changes the test suite to look for rogue DAP exceptions in the
log file, and issue a "fail" if one is found.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
I noticed that the DAP attach test case (and similarly
remoted-dap.exp) had a rogue exception stack trace in the log. It
turns out that an attach will generate a stop that does not have a
reason.
This patch fixes the problem in the _on_stop event listener by making
it a bit more careful when examining the event reason. It also adds
some machinery so that attach stops can be suppressed, which I think
is the right thing to do.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This adds a new parameter to control the DAP logging level. By
default, "expected" exceptions are not logged, but the parameter lets
the user change this when more logging is desired.
This also changes a couple of spots to avoid logging the stack trace
for a DAPException.
This patch also documents the existing DAP logging parameter. I
forgot to document this before.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
