summaryrefslogtreecommitdiffstats
path: root/sys/cddl/dev/dtrace/i386
Commit message (Collapse)AuthorAgeFilesLines
* MFC r285643:kib2015-08-071-4/+4
| | | | | When checking for the valid value of the frame pointer, verify that it belongs to the kernel stack address range for the thread.
* MFC r285041:kib2015-08-051-3/+0
| | | | | Use single instance of the identical INKERNEL() and PMC_IN_KERNEL() macros on amd64 and i386. On i386, correct the lowest kernel address.
* MFC r281915:markj2015-05-291-164/+0
| | | | | | | Make vpanic() externally visible. MFC r281916: Fix DTrace's panic() action.
* MFC r280834:markj2015-04-131-1/+22
| | | | Bound the number of frames traversed when executing the ustackdepth action.
* MFC r267759, r267761markj2014-08-052-10/+5
| | | | | | | | | | | | | | | | | | | | | | r267759: Fix a couple of bugs on amd64 when fetching probe arguments beyond the first five for probes entered through a UD fault (i.e. FBT probes). Specifically, handle the fact that dtrace_invop_callsite must be 16 byte-aligned and thus may not immediately follow the call to dtrace_invop() in dtrace_invop_start(). Also fetch register arguments and the stack pointer through a struct trapframe instead of a struct reg. r267761: Fix some bugs when fetching probe arguments in i386. Firstly ensure that the 4 byte-aligned dtrace_invop_callsite can be found and that it immediately follows the call to dtrace_invop(). Secondly, fix some pointer arithmetic to account for differences between struct i386_frame and illumos' struct frame. Finally, ensure that dtrace_getarg() isn't inlined. It works by following a fixed number of frame pointers to the probe site, so inlining breaks it. PR: 191260
* MFC r262542:markj2014-05-033-5078/+0
| | | | | Move some files that are identical on i386 and amd64 to an x86 subdirectory rather than keeping duplicate copies.
* dtrace disassembler: take the latest/last CDDL code from OpenSolarisavg2013-07-292-194/+1840
| | | | | | | | | | | OpenSolaris version is: 13108:33bb8a0301ab 6762020 Disassembly support for Intel Advanced Vector Extensions (AVX) This corresponds to Illumos-gate (github) version ab47273fedff893c8ae22ec39ffc666d4fa6fc8b MFC after: 3 weeks
* Change UL to ULL since time is 32 bits.gnn2012-07-171-1/+1
| | | | | Pointed out by: avg@ MFC after: 2 weeks
* Add support for walltimestamp in DTrace.gnn2012-07-161-2/+7
| | | | | Submitted by: Fabian Keil MFC after: 2 weeks
* r237748 continuation: fix nopw (0f 1f) behavior with respect to modifiersavg2012-07-061-1/+1
| | | | | | | | | To do: proper merge with Illumos vendor area. Reported by: emaste Tested by: emaste Obtained from: Illumos commit 13442:4adbe6de60c8 MFC after: 5 days
* r237748 continuation: segment-override prefixes are not invalid in long modeavg2012-07-061-4/+4
| | | | | | | | | | | | | Update DTrace disassembler accordingly. The code to treat the prefixes as null prefixes was already in place. Although in practice compilers seem to generate only cs-prefix for use in long NOPs, the same treatment is applied to all of cs, ds, es, ss for consistency. Reported by: emaste Tested by: emaste Obtained from: Illumos commit 13442:4adbe6de60c8 (+ local changes) MFC after: 5 days
* dtrace instruction decoder: add 0x0f 0x1f NOP opcode supportavg2012-06-291-1/+1
| | | | | | | | | | | | | | | | According to the AMD manual the whole range from 0x09 to 0x1f are NOPs. Intel manual mentions only 0x1f. Use only Intel one for now, it seems to be the one actually generated by compilers. Use gdb mnemonic for the operation: "nopw". [1] AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions [2] Software Optimization Guide for AMD Family 10h Processors [3] Intel(R) 64 and IA-32 Architectures Software Developer’s Manual Volume 2 (2A, 2B & 2C): Instruction Set Reference, A-Z Tested by: Fabian Keil <freebsd-listen@fabiankeil.de> (earlier version) MFC after: 3 days
* Integrate a fix for a very odd signal delivery problem foundgnn2012-06-041-7/+12
| | | | | | | by Bryan Cantril and others in the Solaris/Illumos version of DTrace. Obtained from: https://www.illumos.org/issues/789 MFC after: 2 weeks
* Fix DTrace TSC skew calculation:zml2012-06-041-1/+1
| | | | | | | | | | | The skew calculation here is exactly backwards. We were able to repro it on a multi-package ESX server running a FreeBSD VM, where the TSCs can be pretty evil. MFC after: 1 week Submitted by: Jeff Ford <jeffrey.ford2@isilon.com> Reviewed by: avg, gnn
* On i386, fbt probes are implemented by writing an invalid opcode overrstone2011-11-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | certain instructions in a function prologue or epilogue. DTrace has a hook into the invalid opcode fault handler that checks whether the fault was due to an probe and if so, runs the DTrace magic. Upon returning from an invalid opcode fault caused by a probe, DTrace must emulate the instruction that was replaced with the invalid opcode and then return control to the instruction following the invalid opcode. There were a pair of related bugs in the emulation for the leave instruction. The leave instruction is used to pop off a stack frame prior to returning from a function. The emulation for this instruction must move the trap frame for the invalid opcode fault down the stack to the bottom of the stack frame that is being removed, and then execute an iret. At two points in this process, the emulation code was storing values above the current value of the stack pointer. This opened up a window in which if we were two take an interrupt, the trap frame for the interrupt would overwrite the values stored on the stack, causing the system to panic later. The first bug was that at one point the emulation code saves the new value for $esp above the current stack pointer value. The fix is to save this value instead inside of the original trap frame. At this point we do not need the original trap frame so this is safe. The second bug is that when the emulate code loads $esp from the stack, it points part-way through the new trap frame instead of at its beginning. The emulation code adjusts the stack pointer to the correct value immediately afterwards, but this still leaves a one instruction window in which an interrupt would corrupt this trap frame. Fix this by adjusting the stack frame value before loading it into $esp. This fixes panics in invop_leave on i386 when using fbt return probes. Reviewed by: rpaulo, attilio MFC after: 1 week
* With retirement of cpumask_t and usage of cpuset_t for representing aattilio2011-07-041-2/+2
| | | | | | | | | | | | | | | mask of CPUs, pc_other_cpus and pc_cpumask become highly inefficient. Remove them and replace their usage with custom pc_cpuid magic (as, atm, pc_cpumask can be easilly represented by (1 << pc_cpuid) and pc_other_cpus by (all_cpus & ~(1 << pc_cpuid))). This change is not targeted for MFC because of struct pcpu members removal and dependency by cpumask_t retirement. MD review by: marcel, marius, alc Tested by: pluknet MD testing by: marcel, marius, gonzo, andreast
* MFCattilio2011-05-101-21/+1
|\
| * dtrace: remove unused codeavg2011-05-101-21/+1
| | | | | | | | | | | | Which is also useless, IMO. MFC after: 5 days
* | Commit the support for removing cpumask_t and replacing it directly withattilio2011-05-051-4/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today). Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition. The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN while the others are still missing. Userland is believed to be fully converted with the changes contained here. Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386. Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno
* Use atomic load & store for TSC frequency. It may be overkill for amd64 butjkim2011-04-071-1/+1
| | | | | | | | | safer for i386 because it can be easily over 4 GHz now. More worse, it can be easily changed by user with 'machdep.tsc_freq' tunable (directly) or cpufreq(4) (indirectly). Note it is intentionally not used in performance critical paths to avoid performance regression (but we should, in theory). Alternatively, we may add "virtual TSC" with lower frequency if maximum frequency overflows 32 bits (and ignore possible incoherency as we do now).
* Fix typos - remove duplicate "the".brucec2011-02-211-1/+1
| | | | | | PR: bin/154928 Submitted by: Eitan Adler <lists at eitanadler.com> MFC after: 3 days
* dtrace_xcall: no need for special handling of curcpuavg2010-12-071-16/+3
| | | | | | | smp_rendezvous_cpus alreadt does the right thing in a very similar fashion, so the code was kind of duplicating that. MFC after: 3 weeks
* dtrace_gethrtime_init: pin to master while examining other CPUsavg2010-12-071-4/+5
| | | | | | | Also use pc_cpumask to be future-friendly. Reviewed by: jhb MFC after: 2 weeks
* Kernel DTrace support for:rpaulo2010-08-222-126/+286
| | | | | | | | | o uregs (sson@) o ustack (sson@) o /dev/dtrace/helper device (needed for USDT probes) The work done by me was: Sponsored by: The FreeBSD Foundation
* Add a function compatibility function dtrace_instr_size_isa() that onrpaulo2010-08-221-0/+7
| | | | | | FreeBSD does the same as dtrace_dis_isize(). Sponsored by: The FreeBSD Foundation
* Update several places that iterate over CPUs to use CPU_FOREACH().jhb2010-06-111-4/+1
|
* dtrace_gethrtime: improve scaling of TSC ticks to nanosecondsavg2009-07-151-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently dtrace_gethrtime uses formula similar to the following for converting TSC ticks to nanoseconds: rdtsc() * 10^9 / tsc_freq The dividend overflows 64-bit type and wraps-around every 2^64/10^9 = 18446744073 ticks which is just a few seconds on modern machines. Now we instead use precalculated scaling factor of 10^9*2^N/tsc_freq < 2^32 and perform TSC value multiplication separately for each 32-bit half. This allows to avoid overflow of the dividend described above. The idea is taken from OpenSolaris. This has an added feature of always scaling TSC with invariant value regardless of TSC frequency changes. Thus the timestamps will not be accurate if TSC actually changes, but they are always proportional to TSC ticks and thus monotonic. This should be much better than current formula which produces wildly different non-monotonic results on when tsc_freq changes. Also drop write-only 'cp' variable from amd64 dtrace_gethrtime_init() to make it identical to the i386 twin. PR: kern/127441 Tested by: Thomas Backman <serenity@exscape.org> Reviewed by: jhb Discussed with: current@, bde, gnn Silence from: jb Approved by: re (gnn) MFC after: 1 week
* Remove unused variable.ganbold2008-11-251-2/+1
| | | | | | | Found with: Coverity Prevent(tm) CID: 3669,3671 Approved by: jb
* Custom DTrace kernel module files plus FreeBSD-specific DTrace providers.jb2008-05-236-0/+5089
OpenPOWER on IntegriCloud