To follow up, any binaries checked into the gem5 repository are not used by the regressions. The M5_PATH variable isn't set, so it looks for binaries in a default location which is what I have in my earlier email. If you want to change what it's using for hello world, somebody with appropriate access will need to replace that binary on zizzer.
Gabe On Wed, Sep 6, 2017 at 11:26 AM, Alec Roelke <[email protected]> wrote: > Sorry, I meant the hello-world binary, not gem5 itself. The one that's > included along with the rest of the test binaries is the same as what I > have on my system, but different than what the regression server is > running. > > On Wed, Sep 6, 2017 at 2:10 PM, Gabe Black <[email protected]> wrote: > > > Nope, and I wasn't aware there was a binary repository either. > > > > Gabe > > > > On Sep 6, 2017 11:02 AM, "Alec Roelke" <[email protected]> wrote: > > > > > 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 > > _______________________________________________ > > 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
