CDT debugging with 16-bit addressable memories

[Edwin Steiner-3]

Hello CDT community!

First: Thank you for developing and supporting CDT!
It's great to have such software to build upon.

I have a question regarding memory access in the CDT debuggin framework(s):
We are connecting a debugger to the CDT for an architecture that has
addressable units of 16 bits in data memory. Due to this we ran into problems
with the memory view.

Looking into the CDT code I found that MemoryBlock tries to guess the
size of addressable units by looking at the data values returned by
the debugger, which, of course, cannot work reliably.
(org.eclipse.cdt.debug.mi.core.cdi.model.MemoryBlock.longToBytes(long))

We solved the problem temporarily by making our debugger report the
addressable size as an additional field in the -data-read-memory response
and patching MIDataReadMemoryInfo and MemoryBlock so that always
the correct addressable size is returned by getWordSize.
(This matches the behaviour described in the comment of the method
org.eclipse.cdt.debug.core.cdi.model.ICDIMemoryBlock.getWordSize() )

My Question: Is there any cleaner way of making CDT debugging work
with memories with addressable unit > 8-bit? We would much prefer to
use an unpatched upstream version of the CDT.

I also looked at the new DSF debugging framework. I found this code:

        fWordSize     = 1;    // Get this from the launch configuration

in org.eclipse.cdt.dsf.debug.model.DsfMemoryBlockRetrieval.DsfMemoryBlockRetrieval(String, ILaunchConfiguration, DsfSession).

So it looks as if the DSF framework does not handle non-8bit memories,
yet. Am I missing something obvious here?

best regards

Edwin


Comment of org.eclipse.cdt.debug.core.cdi.model.ICDIMemoryBlock.getWordSize():

        /**
         * This method is a misnomer. It should be getAddressableSize. This is how
         * CDT finds out from the CDI client the addressable size of the
         * memory--i.e., how many bytes per address. Some embedded systems have
         * memory with addressable sizes >1. Such backends should make sure to
         * ignore the now deprecated wordSize parameter of
         * ICDIMemoryBlockManagement.createMemory block() and not regurgitate that
         * value in the implementation of this method.
         *
         * @return The addressable size of the memory
         */
        int getWordSize();

This e-mail is strictly confidential and intended only for use by the addressee(s) unless otherwise indicated.
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[John Cortell-4]

Edwin,

It's possible that the gdb/mi reference backend simply wasn't
equipped to intelligently return the access size. If the access size
can be determined from gdb, then that's what the gdb/mi plugin should
be using when initializing the MemoryBlock. Please submit a bug
report and a patch with your approach and I'll look at incorporating
it into the code base.

John

At 05:52 AM 11/6/2009, Edwin Steiner wrote:

>Hello CDT community!
>
>First: Thank you for developing and supporting CDT!
>It's great to have such software to build upon.
>
>I have a question regarding memory access in the CDT debuggin framework(s):
>We are connecting a debugger to the CDT for an architecture that has
>addressable units of 16 bits in data memory. Due to this we ran into problems
>with the memory view.
>
>Looking into the CDT code I found that MemoryBlock tries to guess the
>size of addressable units by looking at the data values returned by
>the debugger, which, of course, cannot work reliably.
>(org.eclipse.cdt.debug.mi.core.cdi.model.MemoryBlock.longToBytes(long))
>
>We solved the problem temporarily by making our debugger report the
>addressable size as an additional field in the -data-read-memory response
>and patching MIDataReadMemoryInfo and MemoryBlock so that always
>the correct addressable size is returned by getWordSize.
>(This matches the behaviour described in the comment of the method
>org.eclipse.cdt.debug.core.cdi.model.ICDIMemoryBlock.getWordSize() )
>
>My Question: Is there any cleaner way of making CDT debugging work
>with memories with addressable unit > 8-bit? We would much prefer to
>use an unpatched upstream version of the CDT.
>
>I also looked at the new DSF debugging framework. I found this code:
>
>         fWordSize     = 1;    // Get this from the launch configuration
>
>in
>org.eclipse.cdt.dsf.debug.model.DsfMemoryBlockRetrieval.DsfMemoryBlockRetrieval(String,
>ILaunchConfiguration, DsfSession).
>
>So it looks as if the DSF framework does not handle non-8bit memories,
>yet. Am I missing something obvious here?
>
>best regards
>
>Edwin
>
>
>Comment of org.eclipse.cdt.debug.core.cdi.model.ICDIMemoryBlock.getWordSize():
>
>         /**
>         * This method is a misnomer. It should be
> getAddressableSize. This is how
>         * CDT finds out from the CDI client the addressable size of the
>         * memory--i.e., how many bytes per address. Some embedded
> systems have
>         * memory with addressable sizes >1. Such backends should make sure to
>         * ignore the now deprecated wordSize parameter of
>         * ICDIMemoryBlockManagement.createMemory block() and not
> regurgitate that
>         * value in the implementation of this method.
>         *
>         * @return The addressable size of the memory
>         */
>         int getWordSize();
>
>This e-mail is strictly confidential and intended only for use by
>the addressee(s) unless otherwise indicated.
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@...
>https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[John Cortell-4]

Oh, and as for DSF...sort of the same thing. The DSF gdb/mi reference backend probably doesn't yet support targets with >1-byte access size, but given a fix for the CDI backend, we'll be able to apply the same improvement to the DSF one.

John

At 05:52 AM 11/6/2009, Edwin Steiner wrote:

Hello CDT community!

First: Thank you for developing and supporting CDT!
It's great to have such software to build upon.

I have a question regarding memory access in the CDT debuggin framework(s):
We are connecting a debugger to the CDT for an architecture that has
addressable units of 16 bits in data memory. Due to this we ran into problems
with the memory view.

Looking into the CDT code I found that MemoryBlock tries to guess the
size of addressable units by looking at the data values returned by
the debugger, which, of course, cannot work reliably.
(org.eclipse.cdt.debug.mi.core.cdi.model.MemoryBlock.longToBytes(long))

We solved the problem temporarily by making our debugger report the
addressable size as an additional field in the -data-read-memory response
and patching MIDataReadMemoryInfo and MemoryBlock so that always
the correct addressable size is returned by getWordSize.
(This matches the behaviour described in the comment of the method
org.eclipse.cdt.debug.core.cdi.model.ICDIMemoryBlock.getWordSize() )

My Question: Is there any cleaner way of making CDT debugging work
with memories with addressable unit > 8-bit? We would much prefer to
use an unpatched upstream version of the CDT.

I also looked at the new DSF debugging framework. I found this code:

        fWordSize     = 1;    // Get this from the launch configuration

in org.eclipse.cdt.dsf.debug.model.DsfMemoryBlockRetrieval.DsfMemoryBlockRetrieval(String, ILaunchConfiguration, DsfSession).

So it looks as if the DSF framework does not handle non-8bit memories,
yet. Am I missing something obvious here?

best regards

Edwin


Comment of org.eclipse.cdt.debug.core.cdi.model.ICDIMemoryBlock.getWordSize():

        /**
        * This method is a misnomer. It should be getAddressableSize. This is how
        * CDT finds out from the CDI client the addressable size of the
        * memory--i.e., how many bytes per address. Some embedded systems have
        * memory with addressable sizes >1. Such backends should make sure to
        * ignore the now deprecated wordSize parameter of
        * ICDIMemoryBlockManagement.createMemory block() and not regurgitate that
        * value in the implementation of this method.
        *
        * @return The addressable size of the memory
        */
        int getWordSize();

This e-mail is strictly confidential and intended only for use by the addressee(s) unless otherwise indicated.
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Edwin Steiner-3]

Hallo John!

Thanks for your fast reply.

Actually we are not using gdb but a custom debugger which implements the
gdb/mi interface. We added the addressable unit size as an extra field that
gdb does not report, i.e. the response by our debugger would look like this
(line breaks for readability):

    ^done,addr="3000",bits-per-addressable-unit="16",memory=[
    {address="0xbb8",data=["0xfffd","0x0","0x567","0xbba"]},
    {address="0xbbc",data=["0x0","0xb","0x0","0x0"]},
    {address="0xbc0",data=["0x300a","0x400b","0x500c","0x600d"]}],
    next-page="3012",next-row="3004",nr-bytes="12",total-bytes="12"

(With 'bits-per-addressable-unit="16",' being the non-standard part.)

While the gdb/mi spec explicitly allows the producer to add fields, I guess
the CDT code base would require a more general approach. Or would such an
addition be acceptable?

I could also look into possibilities of specifying the addressable unit size
in the launch configuration.

Which would be the preferable way to get the size info all the way down to
(or up to) the MemoryBlock?

best regards

Edwin

This e-mail is strictly confidential and intended only for use by the addressee(s) unless otherwise indicated.
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[John Cortell-4]

Ah, well, yes. If the ability to get the addressable size is a custom behavior of your gdb/mi-based debugger engine, then the handling of it will need to be a customization in your version of the gdb/mi backend. It seems to me you should petition the gdb folks for an enhancement so we can standardize on the handling.

Specifying a default addressable size in the launch configuration seems like a good enhancement. Some embedded targets have memory with varying addressable sizes, so the setting won't be very helpful in those situations.

John

At 07:29 AM 11/6/2009, Edwin Steiner wrote:

Hallo John!

Thanks for your fast reply.

Actually we are not using gdb but a custom debugger which implements the
gdb/mi interface. We added the addressable unit size as an extra field that
gdb does not report, i.e. the response by our debugger would look like this
(line breaks for readability):

    ^done,addr="3000",bits-per-addressable-unit="16",memory=[
    {address="0xbb8",data=["0xfffd","0x0","0x567","0xbba"]},
    {address="0xbbc",data=["0x0","0xb","0x0","0x0"]},
    {address="0xbc0",data=["0x300a","0x400b","0x500c","0x600d"]}],
    next-page="3012",next-row="3004",nr-bytes="12",total-bytes="12"

(With 'bits-per-addressable-unit="16",' being the non-standard part.)

While the gdb/mi spec explicitly allows the producer to add fields, I guess
the CDT code base would require a more general approach. Or would such an
addition be acceptable?

I could also look into possibilities of specifying the addressable unit size
in the launch configuration.

Which would be the preferable way to get the size info all the way down to
(or up to) the MemoryBlock?

best regards

Edwin

This e-mail is strictly confidential and intended only for use by the addressee(s) unless otherwise indicated.
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev