| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and
DW_OP_bit_piece are handled the same, but the standard tells us:
- DW_OP_piece: if the piece is located in a register, but does not occupy the
entire register, the placement of the piece within that register is defined
by the ABI.
- DW_OP_bit_piece: if the location is a register, the offset is from the least
significant bit end of the register.
Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the
ABI-specific behaviour for DW_OP_piece.
The default implementation of the hook is the behaviour of DW_OP_bit_piece, so
there should not be any functional changes.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
This converts the type copying code to use the new hash map.
Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently an internal function handler has this prototype:
...
struct value *handler (struct gdbarch *gdbarch,
const struct language_defn *language,
void *cookie, int argc, struct value **argv);
...
Also allow an internal function with a handler with an additional
"enum noside noside" parameter:
...
struct value *handler (struct gdbarch *gdbarch,
const struct language_defn *language, void *cookie,
int argc, struct value **argv, enum noside noside);
...
In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's
expected to return some value with the correct return type.
At least, provided it can do so without side effects, otherwise it should
throw an error.
No functional changes.
Tested on x86_64-linux and aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
This removes finalize_values in favor of adding a new final cleanup.
This is safe now that extension languages are explicitly shut down.
|
|
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
void
the_func (frame_info_ptr frame)
{
for (; frame != nullptr; frame = get_prev_frame (frame))
{
...
}
}
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
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
|
|
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
|
|
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
|
|
Add a new variant of gdbarch_pseudo_register_write that takes a
frame_info in order to write raw registers. Use this new method when
available:
- in put_frame_register, when trying to write a pseudo register to a given frame
- in regcache::cooked_write
No implementation is migrated to use this new method (that will come in
subsequent patches), so no behavior change is expected here.
The objective is to fix writing pseudo registers to non-current
frames. See previous commit "gdb: read pseudo register through
frame" for a more detailed explanation.
Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Change gdbarch_pseudo_register_read_value to take a frame instead of a
regcache. The frame (and formerly the regcache) is used to read raw
registers needed to make up the pseudo register value. The problem with
using the regcache is that it always provides raw register values for
the current frame (frame 0).
Let's say the user wants to read the ebx register on amd64. ebx is a pseudo
register, obtained by reading the bottom half (bottom 4 bytes) of the
rbx register, which is a raw register. If the currently selected frame
is frame 0, it works fine:
(gdb) frame 0
#0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36
36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
(gdb) p/x $ebx
$1 = 0x24252627
(gdb) p/x $rbx
$2 = 0x2021222324252627
But if the user is looking at another frame, and the raw register behind
the pseudo register has been saved at some point in the call stack, then
we get a wrong answer:
(gdb) frame 1
#1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56
56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
(gdb) p/x $ebx
$3 = 0x24252627
(gdb) p/x $rbx
$4 = 0x1011121314151617
Here, the value of ebx was computed using the value of rbx in frame 0
(through the regcache), it should have been computed using the value of
rbx in frame 1.
In other to make this work properly, make the following changes:
- Make dwarf2_frame_prev_register return nullptr if it doesn't know how
to unwind a register and that register is a pseudo register.
Previously, it returned `frame_unwind_got_register`, meaning, in our
example, "the value of ebx in frame 1 is the same as the value of ebx
in frame 0", which is obviously false. Return nullptr as a way to
say "I don't know".
- In frame_unwind_register_value, when prev_register (for instance
dwarf2_frame_prev_register) returns nullptr, and we are trying to
read a pseudo register, try to get the register value through
gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read.
If using gdbarch_pseudo_register_read, the behavior is known to be
broken. Implementations should be migrated to use
gdbarch_pseudo_register_read_value to fix that.
- Change gdbarch_pseudo_register_read_value to take a frame_info
instead of a regcache, update implementations (aarch64, amd64, i386).
In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that
uses a frame instead of a regcache. The version using the regcache
is still used by i386_pseudo_register_write. It will get removed in
a subsequent patch.
- Add some helpers in value.{c,h} to implement the common cases of
pseudo registers: taking part of a raw register and concatenating
multiple raw registers.
- Update readable_regcache::{cooked_read,cooked_read_value} to pass the
current frame to gdbarch_pseudo_register_read_value. Passing the
current frame will give the same behavior as before: for frame 0, raw
registers will be read from the current thread's regcache.
Notes:
- I do not plan on changing gdbarch_pseudo_register_read to receive a
frame instead of a regcache. That method is considered deprecated.
Instead, we should be working on migrating implementations to use
gdbarch_pseudo_register_read_value instead.
- In frame_unwind_register_value, we still ask the unwinder to try to
unwind pseudo register values. It's apparently possible for the
debug info to provide information about [1] pseudo registers, so we
want to try that first, before falling back to computing them
ourselves.
[1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/
Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
Add value::allocate_register, to facilitate allocating a value
representing a register in a given frame (or rather, in the given
frame's previous frame). It will be used in a subsequent patch. I
changed one relatively obvious spot that could use it, to at least
exercise the code path.
Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Some functions related to the handling of registers in frames accept
"this frame", for which we want to read or write the register values,
while other functions accept "the next frame", which is the frame next
to that. The later is needed because we sometimes need to read register
values for a frame that does not exist yet (usually when trying to
unwind that frame-to-be).
value_of_register and value_of_register_lazy both take "this frame",
even if what they ultimately want internally is "the next frame". This
is annoying if you are in a spot that currently has "the next frame" and
need to call one of these functions (which happens later in this
series). You need to get the previous frame only for those functions to
get the next frame again. This is more manipulations, more chances of
mistake.
I propose to change these functions (and a few more functions in the
subsequent patches) to operate on "the next frame". Things become a bit
less awkward when all these functions agree on which frame they take.
So, in this patch, change value_of_register_lazy and value_of_register
to take "the next frame" instead of "this frame". This adds a lot of
get_next_frame_sentinel_okay, but if we convert the user registers API
to also use "the next frame" instead of "this frame", it will get simple
again.
Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This adds the type::is_array_like method and the value_to_array
function.
The former can be used to see whether a given type is known to be
"array-like". This is the currently the case for certain
compiler-generated structure types; in particular both the Ada and
Rust compilers do this.
|
|
value_array requires the passed-in bounds to match the length of the
array_view it is given. This patch removes the redundant "highbound"
parameter.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes value_array to accept an array view. I also replaced an
alloca with a std::vector in array_operation::evaluate. This function
can work on any size of array, so it seems bad to use alloca.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that the printf code for strings, printf_c_string and
printf_wide_c_string, don't take max-value-size into account, but do
load a complete string from the inferior into a GDB buffer.
As such it would be possible for an badly behaved inferior to cause
GDB to try and allocate an excessively large buffer, potentially
crashing GDB, or at least causing GDB to swap lots, which isn't
great.
We already have a setting to protect against this sort of thing, the
'max-value-size'. So this commit updates the two function mentioned
above to check the max-value-size and give an error if the
max-value-size is exceeded.
If the max-value-size is exceeded, I chose to continue reading
inferior memory to figure out how long the string actually is, we just
don't store the results. The benefit of this is that when we give the
user an error we can tell the user how big the string actually is,
which would allow them to correctly adjust max-value-size, if that's
what they choose to do.
The default for max-value-size is 64k so there should be no user
visible changes after this commit, unless the user was previously
printing very large strings. If that is the case then the user will
now need to increase max-value-size.
|
|
History Of This Patch
=====================
This commit aims to address PR gdb/21699. There have now been a
couple of attempts to fix this issue. Simon originally posted two
patches back in 2021:
https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html
https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html
Before Pedro then posted a version of his own:
https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html
After this the conversation halted. Then in 2023 I (Andrew) also took
a look at this bug and posted two versions:
https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html
https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html
The approach taken in my first patch was pretty similar to what Simon
originally posted back in 2021. My second attempt was only a slight
variation on the first.
Pedro then pointed out his older patch, and so we arrive at this
patch. The GDB changes here are mostly Pedro's work, but updated by
me (Andrew), any mistakes are mine.
The tests here are a combinations of everyone's work, and the commit
message is new, but copies bits from everyone's earlier work.
Problem Description
===================
Bug PR gdb/21699 makes the observation that using $_as_string with
GDB's printf can cause GDB to print unexpected data from the
inferior. The reproducer is pretty simple:
#include <stddef.h>
static char arena[100];
/* Override malloc() so value_coerce_to_target() gets a known
pointer, and we know we"ll see an error if $_as_string() gives
a string that isn't null terminated. */
void
*malloc (size_t size)
{
memset (arena, 'x', sizeof (arena));
if (size > sizeof (arena))
return NULL;
return arena;
}
int
main ()
{
return 0;
}
And then in a GDB session:
$ gdb -q test
Reading symbols from /tmp/test...
(gdb) start
Temporary breakpoint 1 at 0x4004c8: file test.c, line 17.
Starting program: /tmp/test
Temporary breakpoint 1, main () at test.c:17
17 return 0;
(gdb) printf "%s\n", $_as_string("hello")
"hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(gdb) quit
The problem above is caused by how value_cstring is used within
py-value.c, but once we understand the issue then it turns out that
value_cstring is used in an unexpected way in many places within GDB.
Within py-value.c we have a null-terminated C-style string. We then
pass a pointer to this string, along with the length of this
string (so not including the null-character) to value_cstring.
In value_cstring GDB allocates an array value of the given character
type, and copies in requested number of characters. However
value_cstring does not add a null-character of its own. This means
that the value created by calling value_cstring is only
null-terminated if the null-character is included in the passed in
length. In py-value.c this is not the case, and indeed, in most uses
of value_cstring, this is not the case.
When GDB tries to print one of these strings the value contents are
pushed to the inferior, and then read back as a C-style string, that
is, GDB reads inferior memory until it finds a null-terminator. For
the py-value.c case, no null-terminator is pushed into the inferior,
so GDB will continue reading inferior memory until a null-terminator
is found, with unpredictable results.
Patch Description
=================
The first thing this patch does is better define what the arguments
for the two function value_cstring and value_string should represent.
The comments in the header file are updated to describe whether the
length argument should, or should not, include a null-character.
Also, the data argument is changed to type gdb_byte. The functions as
they currently exist will handle wide-characters, in which case more
than one 'char' would be needed for each character. As such using
gdb_byte seems to make more sense.
To avoid adding casts throughout GDB, I've also added an overload that
still takes a 'char *', but asserts that the character type being used
is of size '1'.
The value_cstring function is now responsible for adding a null
character at the end of the string value it creates.
However, once we start looking at how value_cstring is used, we
realise there's another, related, problem. Not every language's
strings are null terminated. Fortran and Ada strings, for example,
are just an array of characters, GDB already has the function
value_string which can be used to create such values.
Consider this example using current GDB:
(gdb) set language ada
(gdb) p $_gdb_setting("arch")
$1 = (97, 117, 116, 111)
(gdb) ptype $
type = array (1 .. 4) of char
(gdb) p $_gdb_maint_setting("test-settings string")
$2 = (0)
(gdb) ptype $
type = array (1 .. 1) of char
This shows two problems, first, the $_gdb_setting and
$_gdb_maint_setting functions are calling value_cstring using the
builtin_char character, rather than a language appropriate type. In
the first call, the 'arch' case, the value_cstring call doesn't
include the null character, so the returned array only contains the
expected characters. But, in the $_gdb_maint_setting example we do
end up including the null-character, even though this is not expected
for Ada strings.
This commit adds a new language method language_defn::value_string,
this function takes a pointer and length and creates a language
appropriate value that represents the string. For C, C++, etc this
will be a null-terminated string (by calling value_cstring), and for
Fortran and Ada this can be a bounded array of characters with no null
terminator. Additionally, this new language_defn::value_string
function is responsible for selecting a language appropriate character
type.
After this commit the only calls to value_cstring are from the C
expression evaluator and from the default language_defn::value_string.
And the only calls to value_string are from Fortan, Ada, and ObjectC
related code.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Co-Authored-By: Pedro Alves <pedro@palves.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The scoped_value_mark helper class was setting its internal
mark value to NULL to indicate that the value chain had already
been freed to mark.
However, value_mark() also returns NULL if the value chain is
empty at the time of call.
This lead to the situation that if the value chain was empty
at the time the scoped_value_mark was created, the class
would not correctly clean up the state when it was destroyed,
because it believed it had already been freed.
I noticed this because I was setting a watchpoint very early
in my debug session, and it was becoming a software watchpoint
rather than hardware. Running any command that called evaluate()
beforehand (such as 'x 0') would mean that a hardware watchpoint
was correctly used. After some careful examination of the
differences in execution, I noticed that values were being freed
later in the 'bad case', which lead me to notice the issue with
scoped_value_mark.
|
|
This adds a flags parameter to parse_and_eval.
|
|
Like evaluate_expression, evaluate_type is also just a simple wrapper.
Removing it makes the code a little nicer.
|
|
evaluate_expression is just a little wrapper for a method on
expression. Removing it also removes a lot of ugly (IMO) calls to
get().
|
|
This patch adds a 'frame' parameter to value_at_lazy and ensures that
it is passed down to the call to resolve_dynamic_type. This required
also adding a frame parameter to value_from_contents_and_address.
Nothing passes this parameter to value_at_lazy yet, so this patch
should have no visible effect.
|
|
This adds the two new functions, value_as_mpz and value_from_mpz,
useful for manipulation values via gdb_mpz.
|
|
I noticed a very stale comment in valarith.c. This patch fixes a few
comments in this area.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
value_in is unused. From git log, it seems to have been part of the
Chill language, which was removed from gdb eons ago. This patch
removes the function. Tested by rebuilding.
|
|
There are several more value methods that currently return 'int' but
that should return 'bool'. This patch updates these.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::bits_synthetic_pointer to return bool and fixes up
some fallout from this.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_stack to be a bool and updates the various uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_initialized to be a bool and updates the various
uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_lazy to be a bool and updates the various uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_modifiable to be a bool and updates the various
uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing
all uses with a call to value::lval.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This introduces the set_lval method on value, one step toward removing
deprecated_lval_hack. Ultimately I think the goal should be for some
of these set_* methods to be replaced with constructors; but I haven't
done this, as the series is already too long. Other 'deprecated'
methods can probably be handled the same way.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
At the end of this series, I belatedly realized that values should
only be destroyed by value_decref. This patch marks the the
destructor private to enforce this.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This hoists the 'private' in struct value to also encompass the data
members.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
record_latest_value now access some internals of struct value, so turn
it into a method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This introduces a value::set_modifiable and changes a couple of spots
to use it.
I'm not completely sure the comments by deprecated_modifiable are
correct any more. Perhaps they should be removed and the method
renamed. Like so many before me, though, I've deferred investigation
of the issue.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch turns a grab bag of value functions to methods of value.
These are done together because their implementations are
interrelated.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes preserve_one_value to be a method of value. Much of this
patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This turns value_from_xmethod, result_type_of_xmethod, and
call_xmethod to be methods of value. value_from_xmethod is a static
"constructor" now.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This turns set_value_component_location into a method of value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes value_non_lval and value_force_lval to be methods of
value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This turns many functions that are related to optimized-out or
availability-checking to be methods of value. The static function
value_entirely_covered_by_range_vector is also converted to be a
private method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
