Thanks for pinging me. It's been a busy few weeks. I'll plan on getting to this today or tomorrow. I'm in the process of getting set up on a new computer, so I'll work on this whenever it's set up.
Cheers, Jason On Wed, Sep 20, 2017 at 8:47 AM Alec Roelke <[email protected]> wrote: > Hi Jason, > > Have you had the chance to push test replacements? > > -Alec > > On Wed, Sep 13, 2017 at 12:15 PM, Alec Roelke <[email protected]> wrote: > > > Thanks for your help on this. If there's anything I can do to help, let > > me know. > > > > On Wed, Sep 13, 2017 at 4:12 AM, Jason Lowe-Power <[email protected]> > > wrote: > > > >> I'm going to push a replacement for these tests next week. Hopefully > that > >> will fix things. > >> > >> I'll *try* to test things on zizzer, but it's hard since I wasn't around > >> when it was set up, and I don't have all of the necessary permissions. > We > >> need to move away from zizzer for testing. We're working on it, but it's > >> slow going. > >> > >> Jason > >> > >> On Wed, Sep 13, 2017 at 8:58 AM Gabe Black <[email protected]> > wrote: > >> > >> > 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 > >> _______________________________________________ > >> 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
