I'm compiling an application built with TI's DVSDK 3 *[0].
/home/user/ti/dvsdk/dvsdk_3_01_00_10/linuxutils_2_25_02_08/packages/ti/sdo/linuxutils/cmem/lib/cmem.a470MV(cmem.o470MV):(.ARM.exidx+0x0):
undefined reference to `__aeabi_unwind_cpp_pr0'
arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1) 4.5.2
arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils for Ubuntu) 2.21.0.20110302
More full output is here (but it isn't particularly helpful due to TI's RTSC
make system's black-magic)
https://gist.github.com/925674
FYI: the MV in cmem.a470MV stands for MontaVista.
This name is hard-coded somewhere even though it's not being linked against
a MontaVista system.
I believe the 470 means that it should work with ARMv4 through ARMv7, but
I'm not positive.
My googling suggest that this is a toolchain bug and that the best way
around the issue is to create a file which defines the function as a void
dummy and include it.
http://www.codesourcery.com/archives/arm-gnu/msg03604.htmlhttp://comments.gmane.org/gmane.comp.boot-loaders.u-boot/78649http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=__aeabi_unwind_cpp_pr0
I have a script that I'll post shortly with instructions as to how to setup
TI's DVSDK with Linaro
AJ ONeal
[0] I'm not using the latest DVSDK version 4 because the paths and such are
so hard-coded for the 2009q3 version of codesourcery on ubuntu 10.04 LTS
that I don't know where to start fixing it.
===Progress===
* Patch review week.
* Looked at bootstrap issue for a while but Richard Sandiford picked
it up and sorted it out (Thanks Richard).
* Fun and games with some paperwork.
* Some backporting and testing patches. (50099 and 50186) underway.
=== Plans ===
* Clear out some of the old patches (POST_MODIFY_DISP for vfp,
BRANCH_COST ) and finish on auto-inc-dec patch from last week.
* Away for 1 day next week.
Meetings:
* 1-1s
* TCWG calls
Absences.
* 5th October -Out of Office.
* 13th - 14th October - Internal training.
* 31st Oct - 4th Nov - Linaro Summit Orlando.
* 08 Nov - 11 Nov - Tentatively booked
* Dec 19 - 31st Dec - Tentatively booked
== This week ==
* Applied patch for doing NEON high/low extraction using subregs.
Ramana pointed out that we do the same thing for insertion,
so I wrote a patch to handle that too. Both now merged into
Linaro sources.
* Looked at ARM bootstrap problem on trunk. Turned out to be
an aliasing problem. Submitted and applied patch.
* Reworked part of my SMS register-scheduling patch after feedback
from Ayal. Submitted new version upstream.
* Got SPEC2006 running on the powerpc boxes and tested one part
of my -fsched-pressure patch. Bit of a mixed bag. h264ref was
one of the worst sufferers, which was a bit worrying. I think
I'll need to make a third change too.
To recap, there are two pieces now:
1) Make -fsched-pressure honour the DFA
2) Make -fsched-pressure allow values that are live across a
loop to be spilled.
I naively hoped that (1) would be OK on its own, but h264 shows
that the current -fsched-pressure code is very conservative
when it comes to large blocks. It only considers register
deaths once there is a single remaining use; if there are two
unscheduled uses, it assumes that the register remains live
for the rest of the block.
So the problem that (1) was fixing was that -fsched-pressure was too
optimistic in terms of what it could schedule in a cycle. But with
that fixed, we seem to have too many sources of pessimism...
Richard
== GDB ==
* Worked on support for cross-platform core file generation.
* Followed up on patch to support disabling address space
randomization in gdbserver.
== GCC ==
* Followed up on patch for PR 50305.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
* Working on croos-compiling Firefox. Getting dependencies in place and
setting up the configuration file (.mozconfig). I have had the strategy to
fix one dependency at a time, picking prebuilt packages or building my self.
Michael told me at yesterday's meeting about multistrap, that could possibly
be used for fixing all dependencies at once. I will look into that next
week.
* During this process I have also spent some time reading up on cross
compilation in general and also on autoconf and the GNU build system.
Best Regards
Åsa
== String routines ==
* Got eglibc testing setup happy at last
- Note that -O3 builds generally seem to give a few more errors
that are probably worth looking at
- -march=armv6 -mthumb hit some non-thumb1 instructions (normally
non-lo registers), again worth looking at
- Cross testing to Qemu user mode often stalls, mostly on nptl
tests that abort/fail when run in system/natively
* Sent new version of eglibc/memchr patch upstream
* Now have working newlib test setup and reference set
- next step is to try adding my memchr there
== Other ==
* Testing a QEmu patch with Peter
* Looking at bug 861296 (difference in mmap layouts)
* Adding a few suggestions to the set of cpu hotplug tests.
* Dealing with the Manchester lab cold.
Short week; back on Monday
Dave
== GDB ==
* Committed hardware watchpoint support for gdbserver to mainline,
including two minor changes resulting from review comments;
backported those fixes to Linaro GDB as well.
* Implemented and tested support for disabling address space
randomization in gdbserver; patch posted for review.
* Investigated support for cross-platform core file generation.
== GCC ==
* Patch review week.
* Posted updated patch for PR 50305.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Arnd Bergmann <arnd(a)arndb.de> wrote on 08/26/2011 04:44:26 PM:
> On Thursday 25 August 2011, Russell King - ARM Linux wrote:
> >
> > Arnd, can you test this to make sure your gdb test case still works,
and
> > Mark, can you test this to make sure it fixes your problem please?
>
> Hi Russell,
>
> The patch in question was not actually from me but from Ulrich Weigand,
> so he's probably the right person to test your patch.
> I'm forwarding it in full to Uli for reference.
Hi Arnd, hi Russell,
sorry for the late reply, I've just returned from vacation today ...
I've not yet run the test, but just from reading through the patch
it seems that this will at least partially re-introduce the problem
my original patch was trying to fix.
The situation here is about GDB performing an "inferior function
call", e.g. via the GDB "call" command. To do so, GDB will:
0. [ Have gotten control of the target process via some ptrace
intercept previously, and then ... ]
1. Save the register state
2. Create a dummy frame on the stack and set up registers (PC, SP,
argument registers, ...) as appropriate for a function call
3. Restart via PTRACE_CONTINUE
[ ... at this point, the target process runs the function until
it returns to a breakpoint instruction and GDB gets control
again via another ptrace intercept ... ]
4. Restore the register state saved in [1.]
5. At some later point, continue the target process [at its
original location] with PTRACE_CONTINUE
The problem now occurs if at point [0.] the target process just
happened to be blocked in a restartable system call. For this
sequence to then work as expected, two things have to happen:
- at point [3.], the kernel must *not* attempt to restart a
system call, even though it thinks we're stopped in a
restartable system call
- at point [5.], the kernel now *must* restart the originally
interrupted system call, even though it thinks we're stopped
at some breakpoint, and not within a system call
My patch achieved both these goals, while it would seem your
patch only solves the first issue, not the second one. In
fact, since any interaction with ptrace will always cause the
TIF_SYS_RESTART flag to be *reset*, and there is no way at all
to *set* it, there doesn't appear to be any way for GDB to
achive that second goal.
[ With my patch, that second goal was implicitly achieved by
the fact that at [1.] GDB would save a register state that
already corresponds to the way things should be for restarting
the system call. When that register set is then restored in [4.],
restart just happens automatically without any further kernel
intervention. ]
One way to fix this might be to make the TIF_SYS_RESTART flag
itself visible to ptrace, so the GDB could save/restore it
along with the rest of the register set; this would be similar
to how that problem is handled on other platforms. However,
there doesn't appear to be an obvious place for the flag in
the ptrace register set ...
Bye,
Ulrich
