Discussion:
[platform-debug-dev] Memory view reads before base address
Samantha Chan
2007-12-17 15:12:21 UTC
Permalink
The Debug Platform provides this dialog.
Clients can override this dialog box by providing an adapter to
IAddMemoryBlockTarget from your debug elements.

When the Add Memory Monitor action is invoked, the Memory View asks the
current debug context for an IAddMemoryBlockTarget adapter. If the context
can be adapted to IAddMemoryBlockTarget, then we hand the control over to
the IAddMemoryBlockTarget object. This object becomes responsible to
create a dialog for user input. It is also responsible to add the required
memory blocks.

Look at RetargetAddMemoryBlockAction for details.

Please let me know if you have more questions...

Thanks...
Samantha




Stefan Bylund
<steby-***@public.gmane.org>
Sent by: To
platform-debug-de "Eclipse Platform Debug component
v-***@eclipse developers list."
.org <platform-debug-dev-j9T/***@public.gmane.org>
cc

17/12/2007 09:57 Subject
AM Re: [platform-debug-dev] Memory
view reads before base address

Please respond to
"Eclipse Platform
Debug component
developers list."
<platform-debug-d
ev-j9T/***@public.gmane.org>






Hi,

I tried to implement getMemoryBlockStartAddress(),
getMemoryBlockEndAddress(), and getBigLength() in our custom
IMemoryBlockExtension implementation in such a way that if the user
specifies both an address and a length in our custom show memory dialog,
he will get exactly that memory chunk, otherwise, if the user skips to
specify the length, he will get a dynamic memory chunk where you can
sroll around at will. This behaviour is good enough for me.

However, when source code debugging with GDB in Eclipse/CDT, the add
memory monitor dialog in the Memory view only lets the user specify an
address or expression, not a length.

Who provides this add memory monitor dialog, the debug platform or CDT?
Could this dialog be made adapt to the actual IMemoryBlockExtension
implementation and present an optional length field if
getMemoryBlockStartAddress(), getMemoryBlockEndAddress(), and
getBigLength() return null, null, and -1, respectively? If the length
field is filled in, it will be respected, otherwise you get the
"default" dynamic behaviour. If you don't want to change this dialog in
this manner, is it possible to override it in a public way? What do you
think?

Best regards,
Stefan
Hi,
We have two use cases for the Memory view. Either via a GDB debugging
session in CDT or via a custom view where you can look at memory for a
selected process. For the first case, GDB helps us and fills in "not
available" bytes for incomplete memory blocks. For the other case, I
missed that you can use the two methods below, I just returned null as
is done in CDT's memory block implementation and in an example memory
block implementation I found in a presentation from Samantha. I will
try to use those methods for our custom case and hopefully that will
solve our problem.
Regards,
/Stefan
IMemoryBlockExtension already has APIs that allow clients to specify the
start and end address of the memory block.
- public BigInteger getMemoryBlockStartAddress() throws DebugException;
- public BigInteger getMemoryBlockEndAddress() throws DebugException;
The table renderings should not ask for memory beyond the range as
specified by the start and end address.
In addition, Mikhail is right, the model/engine can also control how it
retrieves memory from the engine. The draw back of this is that the
user
can still scroll beyond the range supported by the backend and will
end up
just getting dummy data populated in the Memory View.
Thanks...
Samantha
"Mikhail
Khodjaiants"
<Mikhail.Khodjaia To
component Sent by: developers
list." platform-debug-de
.org
[platform-debug-dev] Memory 13/12/2007 06:21
view reads before base address
AM
Please respond
to "Eclipse
Platform
Debug component
developers
list."
<platform-debug-d
Hi Stefan,
As far as I understand the Memory view just requests a range of memory.
If the requested memory or part of it is not readable it is up to the
backend to decide to retrieve it or not. Not sure that adding a special
option for it is a good idea.
Mikhail Khodjaiants
-----Original Message-----
Sent: 13 December 2007 10:00
To: Eclipse Platform Debug component developers list.
Subject: Re: [platform-debug-dev] Memory view reads before base address
Stefan,
This is a good idea, and I'd like to add a couple of additional
- You should be able to specify the base/size or start/end address of a
memory block, so you can safely scroll within that region.
- This should become an attribute of an IMemoryBlockExtension. i.e.
(optionally) ensure the base address and size of a memory block are
respected (and thus automatically set the rendering preferences)
Hi,
The Memory view reads a bunch of bytes before the specified base
address. This is bad for some kind of embedded systems and core dumps
where you have many small non-consecutive memory snapshots.
The only way to make the Memory view work on such systems is to choose
"Table Rendering Preferences..." in the Memory view's menu and
deselect "Automatically load next page of memory when scrolled to end
of buffer".
After that the Memory view respects the base address and does not try
to read a bunch of bytes before it. However, in this mode, you can not
scroll down and automatically fetch more memory, which still can be
useful.
Would it be possible if the Memory view was changed so that it always
respects the base address? This would make it much more useful.
Should I file a bug report on this?
Regards,
Stefan
--
Derek
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or
copy the
information in any medium. Thank you.
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--
---------------------------------
Stefan Bylund
Senior Software Engineer
Enea
Skalholtsgatan 9,
Box 1033, SE-164 21 Kista, Sweden
Direct: +46 8 50 71 43 25
Mobile: +46 709 71 43 25
stefan.bylund-***@public.gmane.org
www.enea.com
---------------------------------
Enea - Embedded for Leaders
---------------------------------
Stefan Bylund
2007-12-19 15:10:12 UTC
Permalink
Hi,

Samantha, I tried your suggestion and it works. However, I was a bit
surprised that the ISelection passed to canAddMemoryBlocks() and
addMemoryBlocks() in IAddMemoryBlocksTarget is not the selection in the
current IDebugContextProvider but, if any, the IMemoryBlock(Extension)
that happens to be selected in the memory monitor pane of the memory
view. Wouldn't it be more useful to get the selection in the current
IDebugContextProvider, which defines the context where the memory is
retrieved from? Anyway, I worked around this, and I'm now satisfied with
our custom usage of the memory view.

Regards,
Stefan
Post by Samantha Chan
The Debug Platform provides this dialog.
Clients can override this dialog box by providing an adapter to
IAddMemoryBlockTarget from your debug elements.
When the Add Memory Monitor action is invoked, the Memory View asks the
current debug context for an IAddMemoryBlockTarget adapter. If the context
can be adapted to IAddMemoryBlockTarget, then we hand the control over to
the IAddMemoryBlockTarget object. This object becomes responsible to
create a dialog for user input. It is also responsible to add the required
memory blocks.
Look at RetargetAddMemoryBlockAction for details.
Please let me know if you have more questions...
Thanks...
Samantha
Stefan Bylund
Sent by: To
platform-debug-de "Eclipse Platform Debug component
cc
17/12/2007 09:57 Subject
AM Re: [platform-debug-dev] Memory
view reads before base address
Please respond to
"Eclipse Platform
Debug component
developers list."
<platform-debug-d
Hi,
I tried to implement getMemoryBlockStartAddress(),
getMemoryBlockEndAddress(), and getBigLength() in our custom
IMemoryBlockExtension implementation in such a way that if the user
specifies both an address and a length in our custom show memory dialog,
he will get exactly that memory chunk, otherwise, if the user skips to
specify the length, he will get a dynamic memory chunk where you can
sroll around at will. This behaviour is good enough for me.
However, when source code debugging with GDB in Eclipse/CDT, the add
memory monitor dialog in the Memory view only lets the user specify an
address or expression, not a length.
Who provides this add memory monitor dialog, the debug platform or CDT?
Could this dialog be made adapt to the actual IMemoryBlockExtension
implementation and present an optional length field if
getMemoryBlockStartAddress(), getMemoryBlockEndAddress(), and
getBigLength() return null, null, and -1, respectively? If the length
field is filled in, it will be respected, otherwise you get the
"default" dynamic behaviour. If you don't want to change this dialog in
this manner, is it possible to override it in a public way? What do you
think?
Best regards,
Stefan
Hi,
We have two use cases for the Memory view. Either via a GDB debugging
session in CDT or via a custom view where you can look at memory for a
selected process. For the first case, GDB helps us and fills in "not
available" bytes for incomplete memory blocks. For the other case, I
missed that you can use the two methods below, I just returned null as
is done in CDT's memory block implementation and in an example memory
block implementation I found in a presentation from Samantha. I will
try to use those methods for our custom case and hopefully that will
solve our problem.
Regards,
/Stefan
IMemoryBlockExtension already has APIs that allow clients to specify the
start and end address of the memory block.
- public BigInteger getMemoryBlockStartAddress() throws DebugException;
- public BigInteger getMemoryBlockEndAddress() throws DebugException;
The table renderings should not ask for memory beyond the range as
specified by the start and end address.
In addition, Mikhail is right, the model/engine can also control how it
retrieves memory from the engine. The draw back of this is that the
user
can still scroll beyond the range supported by the backend and will
end up
just getting dummy data populated in the Memory View.
Thanks...
Samantha
"Mikhail
Khodjaiants"
<Mikhail.Khodjaia To
component Sent by: developers
list." platform-debug-de
.org
[platform-debug-dev] Memory 13/12/2007 06:21
view reads before base address
AM
Please respond
to "Eclipse
Platform
Debug component
developers
list."
<platform-debug-d
Hi Stefan,
As far as I understand the Memory view just requests a range of memory.
If the requested memory or part of it is not readable it is up to the
backend to decide to retrieve it or not. Not sure that adding a special
option for it is a good idea.
Mikhail Khodjaiants
-----Original Message-----
Sent: 13 December 2007 10:00
To: Eclipse Platform Debug component developers list.
Subject: Re: [platform-debug-dev] Memory view reads before base address
Stefan,
This is a good idea, and I'd like to add a couple of additional
- You should be able to specify the base/size or start/end address of a
memory block, so you can safely scroll within that region.
- This should become an attribute of an IMemoryBlockExtension. i.e.
(optionally) ensure the base address and size of a memory block are
respected (and thus automatically set the rendering preferences)
Hi,
The Memory view reads a bunch of bytes before the specified base
address. This is bad for some kind of embedded systems and core dumps
where you have many small non-consecutive memory snapshots.
The only way to make the Memory view work on such systems is to choose
"Table Rendering Preferences..." in the Memory view's menu and
deselect "Automatically load next page of memory when scrolled to end
of buffer".
After that the Memory view respects the base address and does not try
to read a bunch of bytes before it. However, in this mode, you can not
scroll down and automatically fetch more memory, which still can be
useful.
Would it be possible if the Memory view was changed so that it always
respects the base address? This would make it much more useful.
Should I file a bug report on this?
Regards,
Stefan
--
Derek
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or
copy the
information in any medium. Thank you.
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--
---------------------------------
Stefan Bylund
Senior Software Engineer
Enea
Skalholtsgatan 9,
Box 1033, SE-164 21 Kista, Sweden
Direct: +46 8 50 71 43 25
Mobile: +46 709 71 43 25
www.enea.com
---------------------------------
Enea - Embedded for Leaders
---------------------------------
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
cdt-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
--
---------------------------------
Stefan Bylund
Senior Software Engineer
Enea
Skalholtsgatan 9,
Box 1033, SE-164 21 Kista, Sweden
Direct: +46 8 50 71 43 25
Mobile: +46 709 71 43 25
stefan.bylund-***@public.gmane.org
www.enea.com
---------------------------------
Enea - Embedded for Leaders
---------------------------------
Samantha Chan
2007-12-19 15:20:14 UTC
Permalink
Hello Stefan,

Thanks for getting back. Please open a defect and I will take a look at
this to see if it is working as expected.

Thanks...
Samantha




Stefan Bylund
<steby-***@public.gmane.org>
Sent by: To
cdt-debug-dev-bou CDT Debug developers list
nces-j9T/***@public.gmane.org <cdt-debug-dev-j9T/***@public.gmane.org>
cc

19/12/2007 10:10 Subject
AM Re: [cdt-debug-dev] Re:
[platform-debug-dev] Memory view
reads before base address
Please respond to
CDT Debug
developers list
<cdt-debug-***@ec
lipse.org>






Hi,

Samantha, I tried your suggestion and it works. However, I was a bit
surprised that the ISelection passed to canAddMemoryBlocks() and
addMemoryBlocks() in IAddMemoryBlocksTarget is not the selection in the
current IDebugContextProvider but, if any, the IMemoryBlock(Extension)
that happens to be selected in the memory monitor pane of the memory
view. Wouldn't it be more useful to get the selection in the current
IDebugContextProvider, which defines the context where the memory is
retrieved from? Anyway, I worked around this, and I'm now satisfied with
our custom usage of the memory view.

Regards,
Stefan
Post by Samantha Chan
The Debug Platform provides this dialog.
Clients can override this dialog box by providing an adapter to
IAddMemoryBlockTarget from your debug elements.
When the Add Memory Monitor action is invoked, the Memory View asks the
current debug context for an IAddMemoryBlockTarget adapter. If the context
can be adapted to IAddMemoryBlockTarget, then we hand the control over to
the IAddMemoryBlockTarget object. This object becomes responsible to
create a dialog for user input. It is also responsible to add the required
memory blocks.
Look at RetargetAddMemoryBlockAction for details.
Please let me know if you have more questions...
Thanks...
Samantha
Stefan Bylund
Sent by: To
platform-debug-de "Eclipse Platform Debug component
cc
17/12/2007 09:57 Subject
AM Re: [platform-debug-dev] Memory
view reads before base address
Please respond to
"Eclipse Platform
Debug component
developers list."
<platform-debug-d
Hi,
I tried to implement getMemoryBlockStartAddress(),
getMemoryBlockEndAddress(), and getBigLength() in our custom
IMemoryBlockExtension implementation in such a way that if the user
specifies both an address and a length in our custom show memory dialog,
he will get exactly that memory chunk, otherwise, if the user skips to
specify the length, he will get a dynamic memory chunk where you can
sroll around at will. This behaviour is good enough for me.
However, when source code debugging with GDB in Eclipse/CDT, the add
memory monitor dialog in the Memory view only lets the user specify an
address or expression, not a length.
Who provides this add memory monitor dialog, the debug platform or CDT?
Could this dialog be made adapt to the actual IMemoryBlockExtension
implementation and present an optional length field if
getMemoryBlockStartAddress(), getMemoryBlockEndAddress(), and
getBigLength() return null, null, and -1, respectively? If the length
field is filled in, it will be respected, otherwise you get the
"default" dynamic behaviour. If you don't want to change this dialog in
this manner, is it possible to override it in a public way? What do you
think?
Best regards,
Stefan
Hi,
We have two use cases for the Memory view. Either via a GDB debugging
session in CDT or via a custom view where you can look at memory for a
selected process. For the first case, GDB helps us and fills in "not
available" bytes for incomplete memory blocks. For the other case, I
missed that you can use the two methods below, I just returned null as
is done in CDT's memory block implementation and in an example memory
block implementation I found in a presentation from Samantha. I will
try to use those methods for our custom case and hopefully that will
solve our problem.
Regards,
/Stefan
IMemoryBlockExtension already has APIs that allow clients to specify the
start and end address of the memory block.
- public BigInteger getMemoryBlockStartAddress() throws DebugException;
- public BigInteger getMemoryBlockEndAddress() throws DebugException;
The table renderings should not ask for memory beyond the range as
specified by the start and end address.
In addition, Mikhail is right, the model/engine can also control how it
retrieves memory from the engine. The draw back of this is that the
user
can still scroll beyond the range supported by the backend and will
end up
just getting dummy data populated in the Memory View.
Thanks...
Samantha
"Mikhail
Khodjaiants"
<Mikhail.Khodjaia To
component Sent by: developers
list." platform-debug-de
.org
[platform-debug-dev] Memory 13/12/2007 06:21
view reads before base address
AM
Please respond
to "Eclipse
Platform
Debug component
developers
list."
<platform-debug-d
Hi Stefan,
As far as I understand the Memory view just requests a range of memory.
If the requested memory or part of it is not readable it is up to the
backend to decide to retrieve it or not. Not sure that adding a special
option for it is a good idea.
Mikhail Khodjaiants
-----Original Message-----
Sent: 13 December 2007 10:00
To: Eclipse Platform Debug component developers list.
Subject: Re: [platform-debug-dev] Memory view reads before base address
Stefan,
This is a good idea, and I'd like to add a couple of additional
- You should be able to specify the base/size or start/end address of a
memory block, so you can safely scroll within that region.
- This should become an attribute of an IMemoryBlockExtension. i.e.
(optionally) ensure the base address and size of a memory block are
respected (and thus automatically set the rendering preferences)
Hi,
The Memory view reads a bunch of bytes before the specified base
address. This is bad for some kind of embedded systems and core dumps
where you have many small non-consecutive memory snapshots.
The only way to make the Memory view work on such systems is to choose
"Table Rendering Preferences..." in the Memory view's menu and
deselect "Automatically load next page of memory when scrolled to end
of buffer".
After that the Memory view respects the base address and does not try
to read a bunch of bytes before it. However, in this mode, you can not
scroll down and automatically fetch more memory, which still can be
useful.
Would it be possible if the Memory view was changed so that it always
respects the base address? This would make it much more useful.
Should I file a bug report on this?
Regards,
Stefan
--
Derek
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or
copy the
information in any medium. Thank you.
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--
---------------------------------
Stefan Bylund
Senior Software Engineer
Enea
Skalholtsgatan 9,
Box 1033, SE-164 21 Kista, Sweden
Direct: +46 8 50 71 43 25
Mobile: +46 709 71 43 25
www.enea.com
---------------------------------
Enea - Embedded for Leaders
---------------------------------
_______________________________________________
platform-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
cdt-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
--
---------------------------------
Stefan Bylund
Senior Software Engineer
Enea
Skalholtsgatan 9,
Box 1033, SE-164 21 Kista, Sweden
Direct: +46 8 50 71 43 25
Mobile: +46 709 71 43 25
stefan.bylund-***@public.gmane.org
www.enea.com
---------------------------------
Enea - Embedded for Leaders
---------------------------------

Continue reading on narkive:
Loading...