So the problem must be that the binary is the wrong version. I just cloned a new copy of gem5 and the binary is the same as what I had in my first copy. Are you sure the one on the regression server is up-to-date?
On Wed, Sep 6, 2017 at 12:41 PM, Gabe Black <[email protected]> wrote: > Note that in your version, there's a segment that starts at file offset 0, > hence including the program header which starts at offset 64. > > Gabe > > On Wed, Sep 6, 2017 at 9:30 AM, Alec Roelke <[email protected]> wrote: > > > When I run readelf on my copy of > > tests/test-progs/hello/bin/riscv/linux/hello, this is the output I get: > > > > Elf file type is EXEC (Executable file) > > > Entry point 0x102a4 > > > There are 5 program headers, starting at offset 64 > > > Program Headers: > > > Type Offset VirtAddr PhysAddr > > > FileSiz MemSiz Flags Align > > > LOAD 0x0000000000000000 0x0000000000010000 > 0x0000000000010000 > > > 0x0000000000068cc3 0x0000000000068cc3 R E 1000 > > > LOAD 0x0000000000068f50 0x0000000000079f50 > 0x0000000000079f50 > > > 0x0000000000001bf8 0x0000000000003320 RW 1000 > > > NOTE 0x0000000000000158 0x0000000000010158 > 0x0000000000010158 > > > 0x0000000000000020 0x0000000000000020 R 4 > > > TLS 0x0000000000068f50 0x0000000000079f50 > 0x0000000000079f50 > > > 0x0000000000000020 0x0000000000000050 R 8 > > > GNU_RELRO 0x0000000000068f50 0x0000000000079f50 > 0x0000000000079f50 > > > 0x00000000000000b0 0x00000000000000b0 R 1 > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .note.ABI-tag .text __libc_freeres_fn > __libc_thread_freeres_fn > > > .rodata __libc_subfreeres __libc_IO_vtables __libc_atexit > > > __libc_thread_subfreeres .eh_frame .gcc_except_table > > > 01 .tdata .preinit_array .init_array .fini_array .data.rel.ro > > > .data .got .sdata .sbss .bss __libc_freeres_ptrs > > > 02 .note.ABI-tag > > > 03 .tdata .tbss > > > 04 .tdata .preinit_array .init_array .fini_array .data.rel.ro > > > > > > This is different than what you got, but the program headers still seem > to > > start at offset 64. The md5sum of my version of hello is this: > > md5sum riscv/linux/hello > > *7ac13479c40f2c9e59572dd6ef79db4d* riscv/linux/hello > > It doesn't seem like version of hello that's on the server is the same as > > the one I have locally, although my git seems to think everything I have > is > > up-to-date. > > > > As an aside, when I run readelf on > > tests/test-progs/hello/bin/x86/linux/hello, I get this: > > > > Elf file type is EXEC (Executable file) > > > Entry point 0x400190 > > > There are 5 program headers, starting at offset 64 > > > Program Headers: > > > Type Offset VirtAddr PhysAddr > > > FileSiz MemSiz Flags Align > > > LOAD 0x0000000000000000 0x0000000000400000 > 0x0000000000400000 > > > 0x000000000007e9c0 0x000000000007e9c0 R E 100000 > > > LOAD 0x000000000007f000 0x000000000057f000 > 0x000000000057f000 > > > 0x0000000000002468 0x00000000000147d0 RW 100000 > > > NOTE 0x0000000000000158 0x0000000000400158 > 0x0000000000400158 > > > 0x0000000000000020 0x0000000000000020 R 4 > > > GNU_STACK 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 > > > 0x0000000000000000 0x0000000000000000 RW 8 > > > LOOS+5041580 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 > > > 0x0000000000000000 0x0000000000000000 8 > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .note.ABI-tag .init .text __libc_freeres_fn .fini .rodata > > > __libc_atexit __libc_subfreeres .eh_frame .gcc_except_table > > > 01 .ctors .dtors .jcr .data.rel.ro .got .got.plt .data .bss > > > __libc_freeres_ptrs > > > 02 .note.ABI-tag > > > 03 > > > 04 > > > > > > This has a different entry point and segments, but its program headers > also > > start at offset 64. But this problem doesn't occur for x86 programs. > > > > On Wed, Sep 6, 2017 at 12:05 PM, Gabe Black <[email protected]> > wrote: > > > > > The test scripts have nothing to do with it. In ELF files, the program > > > header table exists somewhere in the image defined by an offset. That > > > offset could (and usually does) put it in a region which is also part > of > > a > > > segment which an ELF loader would put into memory so that the > > > program/dynamic loader/etc. can look at it at run time. gem5's ELF > loader > > > code compares the offset of the header table against the segments it > > knows > > > about to see if they overlap, and if they do uses the virtual address > of > > > the segment to figure out the virtual address of the header table as > it's > > > been loaded into memory. If the header table doesn't overlap with any > > > segment, it records its address as 0. The RISCV process loader code > > > attempts to read out the program header by using that address. Because > 0 > > > isn't mapped to anything, it blows up. > > > > > > $ readelf -l /dist/m5/regression/test-progs/hello/bin/riscv/linux/ > hello > > > > > > Elf file type is EXEC (Executable file) > > > Entry point 0x10000 > > > There are 1 program headers, starting at offset 64 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr > > > FileSiz MemSiz Flags Align > > > LOAD 0x0000000000001000 0x0000000000010000 > 0x0000000000010000 > > > 0x0000000000004b80 0x0000000000004c10 RWE 1000 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .text .rodata .init_array .fini_array .eh_frame .jcr .data > > .sdata > > > .sbss .bss > > > > > > > > > $ md5sum /dist/m5/regression/test-progs/hello/bin/riscv/linux/hello > > > f6a3aabca242749aecb543fe95abfa73 > > > /dist/m5/regression/test-progs/hello/bin/riscv/linux/hello > > > > > > > > > > > > On Wed, Sep 6, 2017 at 8:30 AM, Alec Roelke <[email protected]> > wrote: > > > > > > > My understanding was that gem5 uses libelf to read the segments of > the > > > > program, which correctly identifies the program header table, entry > > > point, > > > > and data, text, and bss segments (among other things). Are you > saying > > > that > > > > the test scripts cause it to do something different? > > > > > > > > On Wed, Sep 6, 2017 at 5:35 AM, Gabe Black <[email protected]> > > wrote: > > > > > > > > > The loader is using the readBlob function of the SE translating > port > > > > proxy > > > > > which converts a virtual address into a physical one before sending > > out > > > > the > > > > > request. It's being fed the address 0, and that, as you might > expect, > > > > > doesn't map to anything. It gets that address from where the ELF > > loader > > > > > tells it the ELF program header table is. The reason it thinks it's > > at > > > > > address 0 is that it didn't actually find an address for it, since > > the > > > > > program header isn't mapped into the only loadable segment. That > > > segment > > > > > starts at file offset 0x1000, but the ELF program header starts at > > > offset > > > > > 64 (maybe in hex?). That's a little unusual because in my > experience > > > the > > > > > linker likes to put the headers in a loadable segment, but that's > > > what's > > > > on > > > > > zizzer right now. > > > > > > > > > > So basically, I would totally expect it to fail, and I'm surprised > > that > > > > it > > > > > works for you guys at all unless you're using binaries which are > > > > different > > > > > and have the headers within the loadable segment. I looked > > specifically > > > > at > > > > > hello world. > > > > > > > > > > Gabe > > > > > > > > > > On Tue, Sep 5, 2017 at 4:43 PM, Jason Lowe-Power < > > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi Alec, > > > > > > > > > > > > The binaries seem to be up-to-date. They are what is in the gem5 > > repo > > > > as > > > > > of > > > > > > Sept. 3. The error is "fatal: readBlob(0x0, ...) failed". > > > > > > > > > > > > If I run the test without the test script, it works. If I run the > > > test > > > > on > > > > > > my local machine it works. The only thing that's failing is > running > > > the > > > > > > test with the test scripts on zizzer. > > > > > > > > > > > > Anyone else have an idea? > > > > > > > > > > > > Jason > > > > > > > > > > > > On Wed, Aug 30, 2017 at 2:55 PM Jason Lowe-Power < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > I'm not sure. I can look into it, but I'm not sure when I'll > get > > > the > > > > > > > chance. I'll try to do it in the next week or so. If I haven't > > > gotten > > > > > to > > > > > > it > > > > > > > by 9/11, send me another email reminder ;). > > > > > > > > > > > > > > Jason > > > > > > > > > > > > > > On Wed, Aug 30, 2017 at 11:24 AM Alec Roelke < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > >> Hi Everyone, > > > > > > >> > > > > > > >> I've noticed that all of the RISC-V regression tests have been > > > > failing > > > > > > >> every day. They all pass when I run them on my machine with > the > > > > > latest > > > > > > >> gem5. Is the machine running the regressions running the > > correct > > > > > > >> binaries? > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Alec Roelke > > > > > > >> _______________________________________________ > > > > > > >> gem5-dev mailing list > > > > > > >> [email protected] > > > > > > >> http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > gem5-dev mailing list > > > > > > [email protected] > > > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > > > > > _______________________________________________ > > > > > gem5-dev mailing list > > > > > [email protected] > > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > > > _______________________________________________ > > > > gem5-dev mailing list > > > > [email protected] > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > _______________________________________________ > > > gem5-dev mailing list > > > [email protected] > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
