On Thursday 23 February 2012 07:26 PM, Richard Earnshaw wrote:
On 23/02/12 10:27, Aneesh V wrote:
Ok. Agree. I never used to use %function when I wrote assembly
functions earlier. I am sure a lot of code will break if this was
enforced.
If you've not used %function on ARM, then your code is se
On Thursday 23 February 2012 05:17 PM, Ulrich Weigand wrote:
Aneesh V wrote on 23.02.2012 11:27:40:
The "packed" attribute specifies that all struct elements ought to be
considered to have alignment requirement 1 instead of their default
alignment. Thus the whole struct ends up having alignme
On 23/02/12 10:27, Aneesh V wrote:
> Ok. Agree. I never used to use %function when I wrote assembly
> functions earlier. I am sure a lot of code will break if this was
> enforced.
If you've not used %function on ARM, then your code is semantically
broken even if it isn't syntactically broken.
The
Aneesh V wrote on 23.02.2012 11:27:40:
> > The "packed" attribute specifies that all struct elements ought to be
> > considered to have alignment requirement 1 instead of their default
> > alignment. Thus the whole struct ends up having alignment requirement
1;
> > and since the section contains
On Tuesday 21 February 2012 03:27 PM, Dave Martin wrote:
On Mon, Feb 20, 2012 at 06:59:53PM +0100, Ulrich Weigand wrote:
"V, Aneesh" wrote:
I agree that not marking the assembly functions ' %function' is a problem
in the code, so it's not a critical bug. But I would've been happier if
the lin
Oops! Sorry. These mails skipped my Inbox and went into a sub-folder
in my mail client that I hadn't used for a long time. I didn't
realize that I had mails!
On Monday 20 February 2012 11:29 PM, Ulrich Weigand wrote:
"V, Aneesh" wrote:
I agree that not marking the assembly functions ' %functi
On Tue, Feb 21, 2012 at 12:05:54PM +0100, Ulrich Weigand wrote:
> Andrew Stubbs wrote on 21.02.2012 11:56:07:
>
> > I'm not sure, but I believe that the compiler requires (prefers) any
> > structs that you want included inside packed structs to be themselves
> > packed, so you can end up with som
Andrew Stubbs wrote on 21.02.2012 11:56:07:
> I'm not sure, but I believe that the compiler requires (prefers) any
> structs that you want included inside packed structs to be themselves
> packed, so you can end up with some structs with apparently unnecessary
> attributes on them.
I don't see w
On Tue 21 Feb 2012 09:57:12 GMT, Dave Martin wrote:
struct pad_conf_entry {
u16 offset;
u16 val;
} __attribute__ ((packed));
The "packed" attribute specifies that all struct elements ought to be
considered to have alignment requirement 1 instead of their default
alignment.
On Mon, Feb 20, 2012 at 06:59:53PM +0100, Ulrich Weigand wrote:
> "V, Aneesh" wrote:
>
> > I agree that not marking the assembly functions ' %function' is a problem
> > in the code, so it's not a critical bug. But I would've been happier if
> > the linker refused to link it rather than branching
"V, Aneesh" wrote:
> I agree that not marking the assembly functions ' %function' is a problem
> in the code, so it's not a critical bug. But I would've been happier if
> the linker refused to link it rather than branching with the wrong
> instruction. Isn't that a problem?
Well, if the target s
+ linaro-toolchain
Hello Ulrich,
I want to revisit this old thread. Sorry for the sloppy follow-up. But,
this time around I have more data.
On Tue, Mar 15, 2011 at 9:00 PM, Ulrich Weigand
wrote:
> Aneesh V wrote:
>
>> I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
>> un
Aneesh V wrote:
> On Wednesday 16 March 2011 07:14 PM, Ulrich Weigand wrote:
> > The R_ARM_THM_CALL marks the branch instruction as still to be
processed
> > by the final link step. And once you actually *perform* the final
link,
> > e.g. via "gcc -o final a.out", the branch gets indeed converted
Aneesh V wrote on 03/16/2011 10:32:50 AM:
> Can you try this sequence:
>
> arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo1.o
> foo1.c -c
> arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo2.o
> foo2.S -c
> arm-linux-gnueabi-ld -r foo1.o foo2.o
> arm-linu
Hi Ulrich,
On Tuesday 15 March 2011 09:00 PM, Ulrich Weigand wrote:
Aneesh V wrote:
I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
until I added some patches recently. One of these patches introduced an
API (let's say foo()) that has a weakly linked alias(let's say
__fo
Aneesh V wrote:
> I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
> until I added some patches recently. One of these patches introduced an
> API (let's say foo()) that has a weakly linked alias(let's say
> __foo()) and a strongly linked implementation(the real foo()) in an
Hi,
I have an interesting observation that I thought might be interesting
to the tool-chain team.
I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
until I added some patches recently. One of these patches introduced an
API (let's say foo()) that has a weakly linked alias(let
17 matches
Mail list logo
