This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Shorter fast tracepoints
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 29 Oct 2011 11:21:11 +0200
- Subject: Re: [PATCH] Shorter fast tracepoints
- References: <4EAB573C.email@example.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 28 Oct 2011 18:30:36 -0700
> From: Stan Shebs <firstname.lastname@example.org>
> The ugly part is that the 2-byte address is in the low 64K of memory,
> which may or may not be available - GDB has to check
> /proc/sys/vm/mmap_min_addr. Fortunately users can tweak it manually
> (via sysctl) if the preset is to block out all of low memory.
> This brings up two troublesome points about this patch as it stands.
> First, documentation. As it stands, the patch to the manual says
> nothing about fooling with the kernel's mmap_min_addr.
In fact, it says nothing at all about the potential problems you
described in this mail that this patch and the packet you introduced
attempts to solve. Readers might wonder why the packet is even
> Should it? It's very system-specific, and the user would only need
> to do anything special if mmap_min_addr were set to 64K or higher,
> otherwise everything quietly works as desired.
If users of tracepoints need to know about this detail, then yes, the
manual should mention it. We can always qualify any specific info by
its being system-specific, but having the information there for
specific systems, especially popular ones, is a Good Thing.
I have no other comments for the documentation parts of your patch,
they are fine with me. Thanks.