[libre-riscv-dev] spike-sv non-default element widths

[Jacob Lifshay]

try compiling using the -fsanitize=undefined flag and/or running inside
valgrind, that might help. If that doesn't help, i can look in more detail
later (probably tomorrow).

On Fri, Oct 19, 2018, 15:31 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Fri, Oct 19, 2018 at 9:20 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Fri, Oct 19, 2018 at 12:01 PM Luke Kenneth Casson Leighton
> > <lkcl at lkcl.net> wrote:
> > >
> > > yippee!  got it!  finally an sv_reg_t and sv_sreg_t class which do the
> > > right thing, and pass all the unit tests.
> >
> >  *sigh* passed the unit tests, a hello world with more than around 18
> > characters, "hello hello hello\n", results in corrupted output.
> >
> > #include <stdio.h>
> >
> > int main(int argc, char *argv[])
> > {
> >     printf("hello  hello hello\n");
> > }
> >
> > might need your help here jacob.
>
>  damn.  ok.  so i partially tracked it down, by not setting the
> elwidth parameter in the new sv_reg_t class.  the two member elements
> are uint64_t reg and uint8_t elwidth.  by *not* setting elwidth, there
> is no stack / memory corruption.
>
>  what that tells me is that somewhere, an operator-overload / typecast
> is going haywire, and i've no idea where.
>
>  any suggestions on how to track this down?
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>