Menu
▾
▴
Re: [Openocd-development] Fwd: SWD?
|
From: Akos V. <ax...@gm...> - 2011-09-26 11:27:06
|
Also, I get a build error for ./src/transport/swd_libswd_drv_openocd.c.
I suspect it is because I have an x64 system where pointers are 64bits in size.
The lines listed below try to cast a pointer to an int (signed 32bit),
for producing log messages.
I don't know why the address pointed is useful log information, and
don't really know how to make this
piece of code portable between 32bit and 64bit systems, so I'll leave
it up to you.
I quick-fixed it for my machine by changing the cast to (long long
int), and adjusting the printf argument to %LX. That way it builds.
The errors are:
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_8’:
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_32’:
swd_libswd_drv_openocd.c:90: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:90: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_8’:
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_32’:
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_trn’:
swd_libswd_drv_openocd.c:174: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_trn’:
swd_libswd_drv_openocd.c:201: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_log_level_inherit’:
swd_libswd_drv_openocd.c:228: error: cast from pointer to integer of
different size
Regards,
Ákos
On 26 September 2011 00:02, Akos Vandra <ax...@gm...> wrote:
> Hi!
>
> Thank you for the advice, I will do my best to live up to them :)
>
> I'm new to git as well, I tried making the patch you requested:
>
> Cheers,
> Ákos
>
> From 88a430100be4d9685863aa2912173ddc5b83e92f Mon Sep 17 00:00:00 2001
> From: Akos <akos@FM12BQ.(none)>
> Date: Sun, 25 Sep 2011 23:55:36 +0200
> Subject: [PATCH] Fixed two warnings for uninitialized variables
> generating build errors
>
> Two retvals in the functions oocd_swd_transport_init and
> mem_ap_read_buf_u32 have not had their values initialized
> and generated a warning, which cause the build to fail.
> Fixed by initializing these variables to ERROR_OK
> ---
> src/target/arm_adi_v5.c | 2 +-
> src/transport/swd_core.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
> index f529446..1454007 100644
> --- a/src/target/arm_adi_v5.c
> +++ b/src/target/arm_adi_v5.c
> @@ -696,7 +696,7 @@ int mem_ap_read_buf_u32(struct adiv5_dap *dap,
> uint8_t *buffer,
> // uint32_t invalue, adr = address;
> // uint8_t* pBuffer = buffer;
>
> - int i, retval;
> + int i, retval = ERROR_OK;
> uint32_t invalue;
> //count >>= 2;
> // wcount = count;
> diff --git a/src/transport/swd_core.c b/src/transport/swd_core.c
> index 383199f..36191fb 100644
> --- a/src/transport/swd_core.c
> +++ b/src/transport/swd_core.c
> @@ -125,7 +125,7 @@ int oocd_swd_run(struct adiv5_dap *dap){
> // TODO: We are operating on global interface pointer, change it into
> function parameter asap.
> int oocd_swd_transport_init(struct command_context *ctx){
> LOG_DEBUG("entering function...");
> - int retval, *idcode;
> + int *idcode, retval = ERROR_OK;
>
> struct target *target = get_current_target(ctx);
> struct arm *arm = target_to_arm(target);
> --
> 1.7.1
>
>
> On 25 September 2011 23:15, Peter Stuge <pe...@st...> wrote:
>> Hi Akos,
>>
>> Akos Vandra wrote:
>>> Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).
>>
>> 10.10 is soon one year old, which can be a long time in open source.
>>
>> Also keep in mind that pretty much every major distribution is
>> applying significant amounts of patches in their toolchain packages
>> and possibly also system libraries.
>>
>> They intend this to make things better of course, but it can backfire
>> and make the toolchain unusable sometimes. Keep this in mind if you
>> encounter a weird build issue of any package.
>>
>> From many years of use of gcc and binutils I would recommend to use
>> a vanilla toolchain, or at the very least very aggressively pulling
>> toolchain updates from your distribution.
>>
>>
>>> I have been getting some warnings (treated as errors) due to some
>>> retvals didn't have initial value set, but I set them to ERROR_OK,
>>> and now it passes those points.
>>
>> Please send patch(es) for these to the mailing list. Thanks!
>>
>>
>>> It seems like uint32_t is not defined, even though it should be, as
>>> stdint.h is included.
>>
>> stdint.h is included only #ifdef HAVE_STDINT_H. Did you verify with
>> gcc -E or at least in config.h that HAVE_STDINT_H is defined?
>>
>>
>>> Funny thing, if I set the first occurance of uint32_t to unsigned
>>> int, the other ones build fine, which is kinda wierd.
>>
>> It is not funny at all. I find it typical of a toolchain issue. It is
>> bullshit that wastes precious developer time. :\
>>
>>
>>> Also, should we spamming the developer list,
>>
>> Certainly yes. The purpose of the developer list is to carry
>> developer discussion.
>>
>>
>>> or rather continue this discussion personally?
>>
>> Absolutely not.
>>
>>
>>> I'm not familiar with opensource development *at all*,
>>
>> Welcome to open source! It can be a wonderful environment of
>> cooperation and synergy when things align well. It can also be a
>> challenging environment of conflicts and complaints when they don't.
>>
>> Overall I personally find it to be more than worth the trouble, and
>> I think it leads to better software.
>>
>>
>>> so I'm not familiar with list policies either.
>>
>> Again, this is a developer list whose sole purpose is for developer
>> communication. Direct communication should be an exception.
>> (Sometimes it's the right thing of course, just usually it is not.)
>>
>> Please study git and work on becoming fluent with it if you are not
>> already. It is a great tool that supports development in very many
>> ways. Beyond simply keeping track of what happened in the code git
>> when used well allows incredibly efficient review and movement of
>> code between developers in a project. I can recommend the
>> http://progit.org/ book, but start out by just playing with it a
>> little. Make some repositories with some commits and get the basic
>> workflow going. Learning the rest is usually easy. I also recommend
>> the #git IRC channel on freenode, for getting live help.
>>
>>
>> One use for developer mailing lists is to distribute proposed
>> patches, so that they can be reviewed and then included into the
>> public source tree.
>>
>> To make the review step quick and thus make it somewhat likely to
>> actually happen, it is *critical* that the patch is what I call
>> "clean". Maybe all this is obvious to you already, in that case
>> please skip to bottom. The individual points of a clean patch are:
>>
>>
>> * Write a top quality commit message, technically and logically
>>
>> In git repositories it is useful to follow a certain commit message
>> format: (Line numbers added to the left)
>>
>> 1. Description of change, prefer <=60 chars, absmax 74 or even 72 chars
>> 2.
>> 3. Third line and onward hold longer description of change
>> 4. each line absmax 74 chars
>>
>> The first line is used in list views, where one commit is listed per
>> line. This makes it important to have a short and sweet description
>> of the change in the first line. The second line is always left
>> blank. The third line and any number of following lines can and
>> should include background on this part of the code and discuss why
>> this change was made the way it was done instead of some other more
>> obvious way. Ie. document the research that went into this particular
>> change of the code. Including links to web pages with relevant
>> information is helpful, as is links to mailing list messages e.g. on
>> http://marc.info/ which has nice short message links. (Only the m=
>> URL parameter is required for links to a message.)
>>
>> The line length restrictions are in part due to use of 80 char wide
>> terminals, but more importantly they are due to how patches are sent
>> and refered to in email. I.e. even if in an open source project no
>> active developer is using 80 char wide terminals there may be
>> participants on the mailing list who benefit from the shorter lines,
>> in which case it makes sense to keep them short. Also, web based
>> repository viewers tend to not want or be able to present very long
>> first line descriptions.
>>
>> As for the logical quality, it is important to write the first line
>> description of the change so that it makes sense for someone who
>> knows nothing at all about the code, since this is used in list
>> views, and since the background for this code and for why this change
>> was done the way it was done comes only in the later lines, which may
>> not be available from where that list view is. On a web page of
>> course it is, but a list of commits can easily appear in an email,
>> which is read by someone offline on an airplane. A description
>> refering to code they don't have and don't know is useless. Keep it
>> high level, clear and simple. Writing this one line is not
>> neccessarily easy.
>>
>> Writing the third line and onwards is usually easier. Before creating
>> this commit you started at some point, faced with a task, a problem
>> or even a bug ticket, and you then learned some things in order to
>> make the committed code change. Basically you want to make sure that
>> a developer doing review also learns the same things, so that they
>> are able to adequatly review your conclusions, without having to
>> duplicate the time you spent on learning how and why to make the
>> change. A bonus for reviewers is that they learn a lot from code
>> written by others.
>>
>>
>> * Change only one thing per commit
>>
>> From the above discussion on commit message it is clear that in order
>> to write a useful commit message it is critical that one commit only
>> includes one logical change. Otherwise it's impossible to write a one
>> line summary.
>>
>> So what's a "thing" - well any logical change, small or big. It can
>> be about renaming variables in order to prepare for a later commit
>> which does code refactoring. It can also be one bug fix which touches
>> a lot of different places in the code. The developer creating the
>> commit decides on what is the thing, and indeed one part of review is
>> for other developers to give feedback on how their view of this thing
>> align. Sometimes this will lead to reworking the patch to solve the
>> same problem with other logical steps in the code.
>>
>> Besides being common sense, the one thing per commit rule is also
>> technically important, e.g. in order for the git bisect feature to be
>> meaningful, and also for being able to later revert a logical change
>> which has turned out to be a bad idea after all.
>>
>>
>> * Adhere strictly to code style where you work
>>
>> A commit can change lots of different places in the code and for
>> historical reasons it's totally possible that they use different code
>> style. Per the previous point about one thing per commit any code
>> style changes should be a separate commit, even if it is tempting
>> also for me to clean up code when I am anyway working in that area.
>> This is fine, but the critical point is to not commit them together.
>> git add -p will allow to post process changes in a file, before they
>> get committed, so that you can commit style change/cleanup
>> separately. In general, reduce code style changes to an absolute
>> minimum. Not only are style changes very demanding to review (since
>> they usually change large amounts of code) but style changes also
>> clutter repository history, which (and this is important) makes it a
>> lot more work to go back and look at the history of a piece of code,
>> e.g. to compare what the code did a year ago when it worked, with
>> what it does now when it has regressed. A big style change of the
>> code adds enormous overhead to fixing this problem. Get style right
>> the first time. Hopefully review will catch problems, but be careful
>> to try to avoid code style issues.
>>
>>
>> * Do review yourself before creating a commit
>>
>> With git it is amazingly easy to perform review of the changes one
>> has made, using git diff. Always use this to look for all of the
>> above points, before you create the commit. When working in the
>> source files it is easy to get tunnel vision and make some small
>> change that gets forgotten later, when focusing on a particular
>> problem. When looking at git diff output that small change is so
>> obvious, and it can be taken care of without requiring a round trip
>> to any other developer.
>>
>>
>> * Do review yourself before sending commits to anyone else
>>
>> Especially for long gnarly sessions leading to a commit it's possible
>> to still miss something. Reviewing the changes before posting is so
>> easy because they are available as commits in the local repository.
>> git log -p shows each commit with commit message and all changes to
>> the code, and assuming your terminal supports it the output will even
>> be colour coded. Do this before you send a patch to the mailing list
>> (e.g. using git send-email) for review by others, again saving time
>> for others and reducing round trips.
>>
>>
>> This might seem like an aweful lot to keep in mind just for working
>> on some code, but I hope that I was able to give good reasons for
>> each point and if they are summarized, actually it doesn't look
>> like such a mouthful anymore:
>>
>> * Write a top quality commit message, technically and logically
>> * Change only one thing per commit
>> * Adhere strictly to code style where you work
>> * Do review yourself before creating a commit
>> * Do review yourself before sending commits to anyone else
>>
>>
>> I hope this makes sense. Please feel free to ask any questions.
>>
>>
>> //Peter
>> _______________________________________________
>> Openocd-development mailing list
>> Ope...@li...
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>
>
|
