Dear Timur Tabi,
In message 20100616145133.bbde7d81...@gemini.denx.de I wrote:
we add support to U-Boot to conditionally check for the gcc version like
Linux to know when to use -fno-toplevel-reorder? =A0Or do we use a linker
script that would support more versions of gcc at the cost
On Fri, 2010-09-10 at 14:53 -0500, Timur Tabi wrote:
On Fri, Sep 10, 2010 at 2:49 PM, Wolfgang Denk w...@denx.de wrote:
AFAICT you did not reply to this, and the problem is still unsolved.
Do you still have this on your list?
Sorry, I'm confused. What exactly do you want me to do?
In message 1276631305-30648-1-git-send-email...@denx.de you wrote:
From: Peter Tyser pty...@xes-inc.com
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with
the -mrelocatable and -fPIC flags). There's no
On Tue, Jun 15, 2010 at 10:37 PM, Peter Tyser pty...@xes-inc.com wrote:
It looks like the -fno-toplevel-reorder flag is only available in gcc =
4.2 (http://gcc.gnu.org/gcc-4.2/changes.html released May 2007). So, do
we add support to U-Boot to conditionally check for the gcc version like
Dear Timur Tabi,
In message aanlktild0osohtpuqpqwsrzsaxptcqnb_c2s0wtvi...@mail.gmail.com you
wrote:
we add support to U-Boot to conditionally check for the gcc version like
Linux to know when to use -fno-toplevel-reorder? =A0Or do we use a linker
script that would support more versions
Peter Tyser wrote:
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with the
-mrelocatable and -fPIC flags). There's no reason for these applications
to be fully relocatable at this time since no relocation
Timur Tabi wrote:
Peter Tyser wrote:
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with the
-mrelocatable and -fPIC flags). There's no reason for these applications
to be fully relocatable at this time
On Tue, 2010-06-15 at 14:05 -0500, Timur Tabi wrote:
Timur Tabi wrote:
Peter Tyser wrote:
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with the
-mrelocatable and -fPIC flags). There's no reason for
Peter Tyser wrote:
Can you do a 'make clean', then recompile?
That *was* with a 'make clean'.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Tue, 2010-06-15 at 14:20 -0500, Timur Tabi wrote:
Peter Tyser wrote:
Can you do a 'make clean', then recompile?
That *was* with a 'make clean'.
Just to be sure, where did the output in your first email come from? It
looked like a successful compile, but libstubs wasn't recompiled (I
On Tue, 2010-06-15 at 14:05 -0500, Timur Tabi wrote:
Timur Tabi wrote:
Peter Tyser wrote:
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with the
-mrelocatable and -fPIC flags). There's no reason for
From: Peter Tyser pty...@xes-inc.com
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with
the -mrelocatable and -fPIC flags). There's no reason for these
applications to be fully relocatable at this time since
On Tue, 2010-06-15 at 14:45 -0500, Timur Tabi wrote:
Peter Tyser wrote:
Was commenting out the 'ifeq' above necessary? It shouldn't be, so my
first question would be why it was needed.
Probably because I was using an older U-Boot. When I switch to the latest
code, it compiles fine.
Dear Peter Tyser,
In message 1276632905.32134.1535.ca...@petert you wrote:
I think by default its not possible to guarantee function order in gcc's
output if a file contains multiple functions. We could create a basic
Correct. If you check for example the timer example program (build
for
snip
all: $(obj).depend $(OBJS) $(LIB) $(SREC) $(BIN) $(ELF)
@@ -88,7 +89,7 @@ $(LIB): $(obj).depend $(LIBOBJS)
$(ELF):
$(obj)%: $(obj)%.o $(LIB)
- $(LD) -g -Ttext $(STANDALONE_LOAD_ADDR) \
+ $(LD) -g -Ttext $(STANDALONE_LOAD_ADDR)
Wolfgang Denk wrote:
I think the timer code is sufficient to show the problem, and that
your fix helps. If Timur confirms it's working for his secret code
too we should apply this.
Doing this at the top of my source file:
static int __flash_wp(int argc, char *argv[]);
int
Dear Peter,
In message 1276634341.32134.1541.ca...@petert you wrote:
I think the timer code is sufficient to show the problem, and that
your fix helps. If Timur confirms it's working for his secret code
too we should apply this.
Do you want this rolled into the first patch, or sent as
Dear Timur Tabi,
In message 4c17e4f2.70...@freescale.com you wrote:
Doing this at the top of my source file:
static int __flash_wp(int argc, char *argv[]);
int flash_wp(int argc, char *argv[])
{
return __flash_wp(argc, argv);
}
and then adding
Wolfgang Denk wrote:
I think the static int __flash_wp() thing is not even needed
assuming that flash_wp() is the first function in your file.
That's the thing -- I don't want flash_wp() to be the first function in my
file. I would then need a forward reference to all the other functions in
my
Dear Timur Tabi,
In message 4c17ea8d.9080...@freescale.com you wrote:
Wolfgang Denk wrote:
I think the static int __flash_wp() thing is not even needed
assuming that flash_wp() is the first function in your file.
That's the thing -- I don't want flash_wp() to be the first function in my
On Tue, 2010-06-15 at 22:51 +0200, Wolfgang Denk wrote:
Dear Peter,
In message 1276634341.32134.1541.ca...@petert you wrote:
I think the timer code is sufficient to show the problem, and that
your fix helps. If Timur confirms it's working for his secret code
too we should apply
Previously, standalone applications were compiled with gcc flags that
produced relocatable executables on the PowerPC architecture (eg with
the -mrelocatable and -fPIC flags). There's no reason for these
applications to be fully relocatable at this time since no relocation
fixups are performed on
22 matches
Mail list logo
