I added a reference in the class documentation. Should I submit it via a
ticket?
Thanks!
John
On Tue, Mar 15, 2016 at 5:51 PM, Jim Ingham wrote:
> The only other suggestion I have is that the first time we refer to a
> module in this file
> we should say "(see SBModule)" or something like that
The only other suggestion I have is that the first time we refer to a module in
this file
we should say "(see SBModule)" or something like that to make it clear what we
mean by a module.
Other than that this looks good to me.
Jim
> On Mar 15, 2016, at 5:05 PM, John Lindal wrote:
>
> Great!
Great! Attached is the update.
On Thu, Mar 10, 2016 at 6:57 PM, Jim Ingham wrote:
> Few more comments...
>
> +/// If an address comes from an existing module, then it will be resolved
> +/// into an offset from its containing section in that module. That way
> it
> +/// can refer to the same l
Few more comments...
+/// If an address comes from an existing module, then it will be resolved
+/// into an offset from its containing section in that module. That way it
+/// can refer to the same logical location as the module that holds it even
Probably my error, but "location as the module"
Thanks for your patience and feedback! Attached is the updated file.
John
On Wed, Mar 9, 2016 at 3:10 PM, Jim Ingham wrote:
> The relation between section offsets and files is stronger than you are
> stating here. You say:
>
> +/// Represents an address. An address may refer to code or data
The relation between section offsets and files is stronger than you are stating
here. You say:
+/// Represents an address. An address may refer to code or data from an
+/// existing module, or it may refer to something on the stack or heap.
+///
That part is good, but you should use that in th
Here is a refinement of SBAddress. The patch also includes updates to
classes referenced by SBAddress.
Does this read better?
Thanks,
John
On Wed, Mar 9, 2016 at 11:56 AM, Jim Ingham wrote:
> In the case of something like SBAddress, I think it would be better to
> have a class header that exp
In the case of something like SBAddress, I think it would be better to have a
class header that explains file/load addresses and section offset addresses.
Then you can just use the terms in the function documentation, and they can be
shorter and more explicit. Trying to define terms inline like
Having completed my C++ app on top of lldb, I would like to improve the
function-level documentation so others don't have to blunder around in the
dark the way I did :)
Here is a patch for SBAddress.h
If this is the right direction, I will work my way through the rest of the
SB*.h files.
Thanks!
