[parsec-users] Errors running Parsec benchmarks in M5

ef snorlaxgb at gmail.com
Wed Aug 19 21:17:14 EDT 2009

I fixed the following issue with Vips (not body track):

"./bodytrack: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.1' not found
(required by ./bodytrack)
./bodytrack: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
(required by ./bodytrack)"

The Glib library I was using was not comptabile to the diskimage
version(right?), so since i am using the precompiled Cross Compiler listed
under m5sim.org, I am not sure on the work arounds

build_env="CXXFLAGS=\"${CXXFLAGS}  -mcpu=21064\" CFLAGS=\"${CFLAGS}
-mcpu=21064\"  "

2009/8/19 Christian Bienia <cbienia at cs.princeton.edu>

>  Ef,
> The same alignment rules also exist for Sparc CPUs, but the PARSEC
> workloads all run fine on Sparc since at least PARSEC 2.0. On Sparc it’s
> even stricter, if the program performs an unaligned memory access it always
> segfaults. You can go back to the archives of parsec-users and you’ll see
> some reports of workloads that had that issue in the original PARSEC release
> (canneal, for example). It’s all been fixed for a while, so I’m skeptical
> that it’s really an unaligned access issue in the program.
> - Chris
> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *ef
> *Sent:* Wednesday, August 19, 2009 5:41 PM
> *To:* PARSEC Users
> *Subject:* Re: [parsec-users] Errors running Parsec benchmarks in M5
> Regarding the unaligned access I see the error can be detailed here:
> _________________
> http://www.alphalinux.org/faq/FAQ-1.html#ss1.2
> The only exception to this rule is when formatting a new floppy disk. To do
> this, you'll need to select the device name with the correct capacity. For
> example, if the system has a 1.4MB drive, format /dev/fd0H1440 instead of
> /dev/fd0.
> *Unaligned accesses:*
> The Alpha, like all real RISC CPUs, requires that memory accesses are *naturally
> aligned*. For example, reading a 4 byte integer from memory requires that
> the address of the integer be a multiple of 4. Similarly, 8 byte integers
> need to start at an address that is a multiple of 8. If the CPU attempts to
> access a word that is not properly aligned, the CPU will trap into the
> kernel and issue a warning message. The kernel will then go ahead and
> emulate the unaligned access so that the user-level process executes as if
> nothing had happened (except for a substantial slow-down due to the fault).
> Typically, an unaligned fault message looks like this:
> X(26738): unaligned trap at 000000012004b6f0: 00000001401b20ca 28 1
> What this means is that the process executing command X (the X11 server)
> with process id 26738 caused an unaligned fault accessing address
> 0x1401b20ca. This access was performed by the instruction located at address
> 0x12004b6f0. The other numbers are less important, but if you check the
> kernel sources, you'll find that they tell you more info on what kind of
> instruction caused the fault (e.g., a load vs. a store).
> You do not need to be overly alarmed when seeing such a message. The
> program causing the faults will work *correctly*. Eventually, all
> unaligned accesses will be fixed, but in the meantime, just ignore these
> messages (if you're a programmer, please take a minute and fix the source of
> the unaligned access instead...).
> ________________________________
> I think I can go ahead and try to mabe fix the error in the code, however I
> have no clue where to start..
> I can use  the debugger as I have -g enabled but I dont have a true alpha
> machine. Let me know if you have any ideas.
> Thanks
> EF
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20090819/7a830229/attachment.html>

More information about the parsec-users mailing list