This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] btrace: support 32-bit inferior on 64-bit host
- From: Pedro Alves <palves at redhat dot com>
- To: Markus Metzger <markus dot t dot metzger at intel dot com>
- Cc: gdb-patches at sourceware dot org, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Mon, 02 Mar 2015 22:08:18 +0000
- Subject: Re: [PATCH] btrace: support 32-bit inferior on 64-bit host
- Authentication-results: sourceware.org; auth=none
- References: <1423473177-28369-1-git-send-email-markus dot t dot metzger at intel dot com>
On 02/09/2015 09:12 AM, Markus Metzger wrote:
> The heuristic for filtering out kernel addressess in BTS trace checks the
> most significant bit in each address. This works fine for 32-bit and 64-bit
> For 32-bit compatibility mode, i.e. a 32-bit inferior running on 64-bit
> host, we need to check bit 63 (or any bit bigger than 31), not bit 31.
> Use the machine field in struct utsname provided by a uname call to
> determine whether we are running on a 64-bit host.
Does this correctly handle the case of 32-bit GDB on 64-bit system
debugging _32-bit_ inferior? Based on e.g..
$ uname -m
$ i386 uname -m
I'd guess "no".
If I'm right, maybe a better heuristic for kernel bitness would be to look
for long mode in cpuid? I.e., if we're running on a 64-bit CPU.
32-bit kernels on 64-bit CPUs are a dying breed, I think...
> @@ -102,6 +103,32 @@ perf_event_new_data (const struct perf_event_buffer *pev)
> return *pev->data_head != pev->last_head;
> +/* Try to determine the size of a pointer in bits for the OS.
> + *
> + * This is the same as the size of a pointer for the inferior process
> + * except when a 32-bit inferior is running on a 64-bit OS.
> + */
Wrong comment format.
> +static int
> +linux_determine_ptr_bits (void)
Please name this something that indicates "ptr_bits of who".
E.g., linux_determine_host_ptr_bits or linux_determine_kernel_ptr_bits.