Re: [gem5-users] RISC-V DerivO3CPU: Assertion `atomicOpFunctor != NULL' failed

[Alec Roelke]

Hi Hossein,

I'm glad you were able to find a solution to your problem.  The best way to
post code and try to get it merged is to create a patch on Gerrit
, which is the patch review system
gem5 uses.  The CONTRIBUTING file has instructions on how to do that, but
basically you just create a new branch off of master with the changes you
want to make and then do "git push origin HEAD:refs/for/master" and it will
create a patch.  Just make sure you combine all the changes into one
commit, or it will create a new patch to review for all of the commits.

-Alec Roelke

On Thu, Jul 18, 2019 at 1:15 PM Hossein Golestani 
wrote:

> Forwarding a possible solution:
>
>
> -- Forwarded message -
>
> Hi Hossein,
>
> I don't know if there is an update to this on you end, but here is how I
> got around this issue when I tried running some SPEC benchmarks compiled
> for RISC-V on DerivO3CPU.
>
> I guess the problem is related to how Packet objects are created and sent
> to the cache from the LSQ. I've debugged a bit and found that the
> problematic AtomicOpFunctor pointer is valid up to the point where the LSQ
> calls "req->buildPackets();" (@lsq_unit_impl.hh:771). Packets built by this
> call won't have the AtomicOpFunctor in their Request objects and this is
> the cause of the problem. I couldn't find an elegant way to handle this but
> basically what I did was to modify Request class so that I was able to set
> the AtomicOpFunctor in LSQ before the packet is sent to the cache. Here are
> the modifications I've made.
>
> +++ b/src/cpu/o3/lsq_unit_impl.hh
>> @@ -771,10 +771,14 @@ LSQUnit::writebackStores()
>>  req->buildPackets();
>>
>>  DPRINTF(LSQUnit, "D-Cache: Writing back store idx:%i PC:%s "
>> -"to Addr:%#x, data:%#x [sn:%lli]\n",
>> +"to Addr:%#x, data:%#x [sn:%lli] amoOp:%d\n",
>>  storeWBIt.idx(), inst->pcState(),
>>  req->request()->getPaddr(), (int)*(inst->memData),
>> -inst->seqNum);
>> +inst->seqNum, req->_amo_op != NULL);
>> +
>> +
>> +if(req->_amo_op != NULL)
>> +req->request()->setAtomicOpFunctor(req->_amo_op);
>>
>>  // @todo: Remove this SC hack once the memory system handles it.
>>  if (inst->isStoreConditional()) {
>>
>> +++ b/src/mem/request.hh
>> @@ -679,6 +679,12 @@ class Request
>>  return atomicOpFunctor;
>>  }
>>
>> +void
>> +setAtomicOpFunctor(AtomicOpFunctor* atm)
>> +{
>> +atomicOpFunctor = atm;
>> +}
>> +
>>  /** Accessor for flags. */
>>  Flags
>>  getFlags()
>>
>
> Ideally I'd like to respond to the thread you've posted on the mailing
> list but I don't know if I am able to do it.
>
> Thanks,
> Ataberk
>
> On Thu, Jun 13, 2019 at 12:28 PM Hossein Golestani 
> wrote:
>
>> Hi,
>>
>> I'm using gem5 for simulation of cross-compiled RISC-V programs.
>>
>> I receive the following error when using the DerivO3CPU model:
>> gem5.opt: build/RISCV/mem/request.hh:678: AtomicOpFunctor*
>> Request::getAtomicOpFunctor(): Assertion `atomicOpFunctor != NULL' failed.
>>
>> I have used this command:
>> $GEM5/build/RISCV/gem5.opt --outdir=$OUTDIR \
>> $GEM5/configs/example/se.py \
>> --cpu-type=DerivO3CPU \
>> --l1d_size=64kB \
>> --l1i_size=16kB \
>> --l2_size=1MB \
>> --caches \
>> --l2cache \
>> --cmd=$BINARY --options="$OPTIONS"
>>
>> If I fast-forward the beginning instructions of the program, I will
>> receive the exact same error at some point later.
>>
>> Note that I have no issues with simulating this program with the
>> TimingSimpleCPU model.
>>
>> I found this email (link
>> ) in the
>> gem5 user emails archive, which says the O3 CPU model may have not been
>> tested with RISC-V. However I'd really appreciate any help to get around
>> this issue. I have started to work with gem5 for a few weeks, but I'm
>> willing to modify its code if necessary.
>>
>> Thanks,
>> Hossein
>>
>>
>> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Remote gdb debug interface for RISCV/gem5.debug

[Alec Roelke]

Hi John,

The GDB you're using should be fine.  Your error is most likely a bug in
the GDB implementation in the RISC-V ISA within gem5.  I can take a look at
it over the next week or so, but if you find a fix for it yourself don't
hesitate to submit a patch.

-Alec Roelke

On Wed, Jul 17, 2019 at 3:19 PM John Liu  wrote:

> Hi, colleges,
>
> I'm trying to use remote gdb debug for RISCV/gem5.debug in FS mode. The
> binaries file I used to try this interface is the Berkely boot loader and
> it has been able to boot in FS mode.
>
> * I enabled the "wait_for_remote_gdb" Params in BaseCPU.py and this Params
> worked.
>   But GDB part (riscv64-unknown-elf-gdb) returned glitch.
>
> * I tried the "hello world" binary with riscv64-unknown-elf-gdb in SE
> mode.
>   The similar glitch happened.
>
> * I also tried the remote debug the Berkeley boot loader in Qemu with the
> same gdb tool. It works.
>
> Did I pick the wrong Riscv GDB tool for gem5? Did I miss anything?
>
> Any opinion will be helpful. I appreciate your time and help!
>
> Attached are the commands I used and the message I got:
> ** Commands
> *** The command I used for FS mode is :
>   build/RISCV/gem5.debug configs/example/riscv_fs.py
> *** The command  I used for remote gdb is:
>   riscv64-unknown-elf-gdb -f bbl3
>   (gdb) target remote : 7000
>
> ** Messages
> *** The message I got from Gem5:
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 compiled Jul 17 2019 11:55:28
> gem5 started Jul 17 2019 11:59:25
> gem5 executing on riscv_fs, pid 14710
> command line: build/RISCV/gem5.debug configs/example/riscv_fs.py
>
>
> Global frequency set at 1 ticks per second
> warn: DRAM device capacity (8192 Mbytes) does not match the address range
> assigned (32768 Mbytes)
> info: kernel located at: /home/ riscv_fs/gem5/gem5_ad2039/bbl3
> 0: system.remote_gdb: listening for remote gdb on port 7000
> info: system.cpu: Waiting for a remote GDB connection on port 7000.
>   0: system.remote_gdb: remote gdb attached
> start load DTB file/home/riscv_fs/gem5/gem5_ad2039/cpu.dtb
> Beginning simulation!
> info: Entering event queue @ 0.  Starting simulation...
> warn: Couldn't read data from debugger.
>   0: system.remote_gdb: remote gdb detached
> This is bbl's dummy_payload.  To boot a real kernel, reconfigure bbl
> with the flag --with-payload=PATH, then rebuild bbl. Alternatively,
> bbl can be used in firmware-only mode by adding device-tree nodes
> for an external payload and use QEMU's -bios and -kernel options.
>
> chosen {
> riscv,kernel-start = ;
> riscv,kernel-end = ;
> };
> *** message I got from gdb is:
> Remote debugging using : 7000
> Remote 'g' packet reply is too long (expected 532 bytes, got 1468 bytes):
> 2010008003002d1114200a003f702f5d