[Bug 16511] New: FreeBSD ProcessMonitor.cpp uses AMD64 register names unconditionally

Bug ID 16511
Summary FreeBSD ProcessMonitor.cpp uses AMD64 register names unconditionally
Product lldb
Version unspecified
Hardware PC
OS other
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@cs.uiuc.edu
Reporter rmh@gnu.org
Classification Unclassified

Created attachment 10803 [details]
untested patch to fix build on i386-kfreebsd-gnu (and possibly i386-freebsd)

I found this on GNU/kFreeBSD, but I believe FreeBSD would be affected as well.
Please let me know if I may be missing something.

As you can see in last attempted build for i386-kfreebsd-gnu [1],
ProcessMonitor.cpp won't build because it's referring to registers which exist
on AMD64, but not on IA32.

I think this could be fixed using special case for i386 and amd64. Please see
attached patch (UNTESTED).


Thanks for the patch, Robert,

I suspect that using pre-processor logic to determine the architecture will only help in the case where lldb is compiled using the same architecture as the debug target. For instance, when running an i386 application on x86_64, the lower register half of the x86_64 registers should be reported.

Options include removing the logging code, adding parameters to PtraceWrapper to specify the target architecture, lifting the code to a base class of ReadRegOperation and ReadGPROperation, or lifting the code to RegisterContext_x86_64/RegisterContext_i386. If maintaining the logging code is preferred, please consider limiting the log to the case where “log enable” uses the --verbose parameter.


  • Ashok

I'll see if I can implement one of these approaches along with other
refactoring or cleanup work later on, but for now I fixed this by just
punting on this debugging for non-x86_64.

emaste@freebsd.org changed bug 16511

What Removed Added
Resolution FIXED
Assignee lldb-dev@cs.uiuc.edu emaste@freebsd.org

Comment # 1 on bug 16511 from emaste@freebsd.org

Fixed in r186871.  I just wrapped the existing debug in #ifdef __amd64__,
because this diag needs to be cleaned up for all archs anyway and I don't want
the current hack to proliferate.