From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mkimage: SEGFAULT with imximage on 64 bit systems
Date: Fri, 29 Jan 2010 11:04:59 -0500 [thread overview]
Message-ID: <201001291104.59853.vapier@gentoo.org> (raw)
In-Reply-To: <1264760533-17490-1-git-send-email-sbabic@denx.de>
On Friday 29 January 2010 05:22:13 Stefano Babic wrote:
> Running mkimage to generate an imximage produces a SEGFAULT
> on 64 bit machines due to pointer arithmetic limited to 32 bit.
man this is terrible terrible code. using 64bit casts may fix 64bit systems,
but doesnt seem right on 32bit systems as you'd introduce more pointer/size
mismatches.
just glancing through this file shows other random issues:
- the structs seem to overlay the file on disk ? but there's no code to
do target endianness to host endianness translation ?
- the structs are missing ((packed)) attributes
> - ext_header = (flash_cfg_parms_t *) ((uint32_t)&imx_hdr->dcd_table +
> + ext_header = (flash_cfg_parms_t *) ((uint64_t)&imx_hdr->dcd_table +
> sizeof(dcd_preamble_t) + size);
if the only thing you want is imx_hdr->ext_header, why not do it that way:
ext_header = &imx_hdr->ext_header
hardcoding the layout of a struct into random places in the source is asking
for unnecessary trouble.
> base_offset = fhdr->app_dest_ptr + hdr->flash_offset ;
> - fhdr->dcd_ptr_ptr = (uint32_t) ((uint32_t)&fhdr->dcd_ptr -
> - (uint32_t)&fhdr->app_code_jump_vector) + base_offset ;
> + fhdr->dcd_ptr_ptr = (uint32_t) ((uint64_t)&fhdr->dcd_ptr -
> + (uint64_t)&fhdr->app_code_jump_vector) + base_offset ;
you dont need casts to do simple pointer arithmetic:
fhdr->dcd_ptr_ptr = (uint32_t) (&fhdr->dcd_ptr - &fhdr->app_code_jump_vector)
+ base_offset;
(there also shouldnt be a space before that semicolon)
then again, this looks like you're doing constant subtraction. the distance
between two struct members is always going to be the same, so why dont you use
offsetof() to avoid the random pointer ugliness.
> /* The external flash header must be at the end of the DCD table */
> - ext_header = (flash_cfg_parms_t *) ((uint32_t)&hdr->dcd_table +
> + ext_header = (flash_cfg_parms_t *) ((uint64_t)&hdr->dcd_table +
> dcd_len +
> sizeof(dcd_preamble_t));
same issue as the first hunk
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100129/83bc403f/attachment.pgp
next prev parent reply other threads:[~2010-01-29 16:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-29 10:22 [U-Boot] [PATCH] mkimage: SEGFAULT with imximage on 64 bit systems Stefano Babic
2010-01-29 16:04 ` Mike Frysinger [this message]
2010-01-29 16:57 ` Stefano Babic
2010-02-05 14:16 ` [U-Boot] [PATCH V2] " Stefano Babic
2010-02-23 1:34 ` Kim Phillips
2010-02-23 23:07 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201001291104.59853.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox