- Rework quick stack range check as suggested by Ingo.
- If the ref count is > 1 we invoke the debugger unconditionally.
- If equal to 1, we first perform a quick heuristic check to see if the
var might be on the stack. If we can't conclusively determine that is,
we make certain by comparing to the thread's actual stack range.
- If a BReferenceable object is deleted with a non-zero reference count,
we now test to see if the object was allocated on the stack. If so,
we don't flag a warning if the reference count is currently 1.
Slightly amended patch from Tyler Dixon. This fixes #8434.
Tested on my new GPT-disk with:
jam run ":<build>makebootable" --dry-run /dev/sda4
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* It's painfully obvious to me now that we will
need to manage our own framebuffers still in
the latest gallium code.
* GalliumFramebuffer works pretty cleanly as a
class.. we have to remember to lock and unlock
the Framebuffer object however when we access
fBuffer directly. (which needs to occur by design)
* I'm really starting to have problems with the
amount of downcasting Gallium3D does now.
- Since we currently limit the maximum number of child elements we'll
show, it's helpful information to know the actual capacity of the list
in case it contains more, especially when we later support requesting
additional elements to be retrieved.
- Since BasicTargetInterface is a BReferenceable, we must not create it
on the stack, else it will be destroyed while others still have
references to it. Fixes various random crashes, though most frequently
observable when typecasting with more complex types.
Love this feature, but, color schema is not a thing, it is a color
scheme. Change both the display text and the variable names.
Also changed "Retro Terminal" color scheme to just "Retro". Terminal
is redundant.
The value computed isn't actually used anywhere. It just ensured that
a panic would be triggered if we "skipped" to virtual addresses further
along. This shouldn't be problematic however.
This makes it less likely that uninitialized entries cause troubles.
Also panic if we encounter an unknown entry type instead of defaulting
to 4K pages.
And actually use the virtual address for it later on. This wasn't
problematic as the virtual and physical addresses are identity mapped,
but it seems more correct to do it in this order.
- BListValueNode now also handles BObjectLists. In the latter's case
however, it uses the template type parameters to map the array
elements to their actual type. As before, this requires a debug
libbe to function.
- Keep a unified list in DIEClassBaseType so that the order
of template parameters is preserved in cases when type and
value parameters are mixed. Thanks Ingo for the hint.
- Introduce new base Type TemplateParameter, which represents either
a template type or template value parameter, a list of which is
attached to CompoundType.
- Add DwarfTemplateParameter implementing subclass of TemplateParameter
and adjust DwarfTypeFactory accordingly for the above changes.
- Adjust CompoundType to add accessors for template type and value
parameters.
- Add DwarfCompoundType/DwarfTypeFactory handling for template
template type parameters.
- When a debugging libbe is present, and a BList is encountered,
we now read its internal structure and expose it as if it were an
array of pointers. Combined with typecasting, this means one can
now easily inspect the content of such a list.
* The hashtable stored complete Inode objects (albeit without the actual block).
* Now we only store the block_run which should reduce the memory footprint
considerably; before "recover" could easily run out of memory. In any case,
a 64 bit version would still make sense to have :-)
* Saved an extra hash table traversal by counting the node types directly.
* This isn't that well tested yet, though.
