On Tue, Jun 06, 2017 at 05:28:52PM -0700, Ricardo Neri wrote:
> I see. You were more concerned about the naming of the coding artifacts
> (e.g., function names, error prints, etc) than the actual filenames.
Well, I'm not sure here. We could either have a generalized prefix or
put the function name
On Fri, May 05, 2017 at 11:17:11AM -0700, Ricardo Neri wrote:
> This function returns the default values of the address and operand sizes
> as specified in the segment descriptor. This information is determined
> from the D and L bits. Hence, it can be used for both IA-32e 64-bit and
> 32-bit legac
On Fri, May 05, 2017 at 11:17:12AM -0700, Ricardo Neri wrote:
> Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
> Developer's Manual volume 2A states that when ModRM.mod is zero and
> ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means
> that none of the regi
On Fri, May 05, 2017 at 11:17:14AM -0700, Ricardo Neri wrote:
> The 32-bit and 64-bit address encodings are identical. This means that we
> can use the same function in both cases. In order to reuse the function
> for 32-bit address encodings, we must sign-extend our 32-bit signed
> operands to 64-
On Fri, May 05, 2017 at 11:17:14AM -0700, Ricardo Neri wrote:
> @@ -697,18 +753,21 @@ void __user *insn_get_addr_ref(struct insn *insn,
> struct pt_regs *regs)
> {
> unsigned long linear_addr, seg_base_addr, seg_limit;
> long eff_addr, base, indx;
> - int addr_offset, base_offset,
On Fri, May 05, 2017 at 11:17:16AM -0700, Ricardo Neri wrote:
> Tasks running in virtual-8086 mode or in protected mode with code
> segment descriptors that specify 16-bit default address sizes via the
> D bit will use 16-bit addressing form encodings as described in the Intel
> 64 and IA-32 Archit
On Fri, May 05, 2017 at 11:17:18AM -0700, Ricardo Neri wrote:
> User-Mode Instruction Prevention is a security feature present in new
> Intel processors that, when set, prevents the execution of a subset of
> instructions if such instructions are executed in user mode (CPL > 0).
> Attempting to exe
Hi Ricardo, would you mind unsubscribing
linux-msdos@ from all your future mails on
this subject? Otherwise I am afraid there
would be no subscribers left when you are
finally done. :)
I think all non-kernel-dev MLs should be
treated with more care. Eg your initial
questions were certainly on-topi