object files. Thus static functions will be found, too.
* debug_lookup_symbol_address() and debug_next_image_symbol() no longer
need to read the symbol name via the debugger API, since the
respective SymbolLookup methods compute the length of the symbol name
that can safely be accessed locally, now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27628 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a S_EXTENDED_TYPES constant to simplify some checks.
* Simplified the fAllowDuplicates computation in BPlusTree::SetTo().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27625 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Replaced my bogus comment that Ingo pointed out with a description that
mentions LogicalPartitions also being used to describe so called "inner
extended" partitions, which are only needed to point to the next PTS.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27624 a95241bf-73f2-0310-859d-f6bbb57e9c96
* wait_for_timer() now detects if it has been called from within the timer
execution thread, and will return in error instead of waiting for itself
forever. This fixes bug #2682.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27620 a95241bf-73f2-0310-859d-f6bbb57e9c96
intended. I am wondering though about the offset that is passed to the
logical partitions. If I am not confused, later partitions still use the
primary partition's offset as base offset, so I am wondering if more than
two non-extended logical partitions would work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27614 a95241bf-73f2-0310-859d-f6bbb57e9c96
a B_DEBUGGER_MESSAGE_TEAM_CREATED, so we have to immediately start
profiling the main thread.
Profiling child processes basically works now, but since we still don't
track image creation/deletion, the results aren't correct yet (that is
library symbols might keep the same addresses).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27608 a95241bf-73f2-0310-859d-f6bbb57e9c96
structures still have the parent IDs, so finding an image by ID would
fail in this case. We do now fall back to getting the image's text base
address and finding the image by address.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27607 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added global hash table for images.
* Improved a bit of code by using the new image hash table. E.g.
_get_image_info() can return infos for images of any team, now.
* Fixed remove_images() comment: The function must not be invoked with
the team lock being held.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27606 a95241bf-73f2-0310-859d-f6bbb57e9c96
processes recursively. In practice that doesn't really work, though, for
mainly two reasons:
* The runtime loader doesn't update it's image IDs, so the symbol lookup
doesn't work. Even, if the runtime loader would do that, we are
notified before it had a chance to do it.
* We're not tracking image creation/deletion yet, particularly fork()
+ exec*() leaves us totally clueless. Tracking images is quite unhandy
with the current profiling API, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27603 a95241bf-73f2-0310-859d-f6bbb57e9c96
creation), we didn't release the team debug info spinlock and reenabled
interrupts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27602 a95241bf-73f2-0310-859d-f6bbb57e9c96
called with the window lock held, so it's not a good idea to wait for a
thread that may also lock the window. Now, it no longer does that, but just
sends a B_INVALIDATE message instead of calling Invalidate() directly.
* This closes bug #2737.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27599 a95241bf-73f2-0310-859d-f6bbb57e9c96
various system information.
* Implemented retrieving some VM stats via this call.
* The VM now maintains a page fault counter, and sets system_info::page_faults
accordingly.
* Added a (pretty simple) "vmstat" command line app.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27597 a95241bf-73f2-0310-859d-f6bbb57e9c96
messages easily hit the previous limit. Maybe another solution should be
sought.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27591 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extended the BMenuField test to see what happens when the super item label
changes (works fine now).
* Updated TODO.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27586 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The layout friendly constructors don't need to mess with the control size.
* The layout friendly constructors can use the respective BControl constructor.
* Refactored some duplicated code.
* Removed duplicated GetFontHeight() calls.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27585 a95241bf-73f2-0310-859d-f6bbb57e9c96
doing a lot of these things the same way as BMenuField are already doing.
Perhaps a private helper class could be refactored from these two controls
to avoid duplicating a lot of this code, although there are a few subtle
differences here and there.
These changes make a BTextControl behave properly in the layout management
frame work, in case CreateLabelLayoutItem() and CreateTextViewLayoutItem()
are _not_ used to layout the BTextControl.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27584 a95241bf-73f2-0310-859d-f6bbb57e9c96
MaxSize(). This makes sure that MaxSize() returns a proper size when the
user "unsets" the explicite max size.
* minimum label height is 0 if there is no label.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27583 a95241bf-73f2-0310-859d-f6bbb57e9c96
