https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Henrik Brix Andersen changed:
What|Removed |Added
CC||henrik at brixandersen dot dk
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Alex Underwood changed:
What|Removed |Added
CC||alexander.underwood@okstate
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #3 from Liwei.Ma at armchina dot com ---
Hi, Alex,
I also confirm this bug, while my version seems to be stuck at little endian. I
am using ubuntu 20.04.3 package, aarch64-linux-gnu-objcopy (2.34),
aarch64-linux-gnu-gcc (9.3.0).
A
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
gökçe changed:
What|Removed |Added
CC||sourceware.org at aydos dot de
--- Comment #4
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Nick Clifton changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #6 from Nick Clifton ---
Created attachment 14432
--> https://sourceware.org/bugzilla/attachment.cgi?id=14432&action=edit
Proposed patch
Please can somebody try out this patch ?
It *might* work, but all this endian-ness stuff i
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Nick Clifton changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--
You are receiving this mai
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Nick Clifton changed:
What|Removed |Added
Attachment #14432|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #8 from gökçe ---
Thanks for the fast response :)
```
--- /dev/null 2022-11-03 08:18:45.269001160 +
+++ 2022-11-03 13:29:21.965562457 +
```
I suppose the testname is missing Nick.
--
You are receiving this mail be
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #9 from Gökçe Aydos ---
I tested the patch (without the test). My remarks:
1) AFAIK memory addresses are byte addresses in gcc. If --verilog-data-width is
greater than 1, then each word in the pattern file becomes something else t
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #10 from Nick Clifton ---
(In reply to Gökçe Aydos from comment #9)
> I tested the patch (without the test). My remarks:
Thanks for testing it.
> 1) AFAIK memory addresses are byte addresses in gcc. If --verilog-data-width
> is g
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Nick Clifton changed:
What|Removed |Added
Attachment #14433|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #12 from Gökçe Aydos ---
(In reply to Nick Clifton from comment #10)
> >> As the file is read, each number encountered is assigned to a successive
> >> word element of the memory.
>
> In that sentence, what exactly is meant by "
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #13 from Olof Kindgren ---
Great to see some activity on this! I haven't compiled and tested it myself
yet, but I'm wondering if we got the addressing right. Nick, it's correct that
we are dealing with word addresses, but are we ta
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #14 from Gökçe Aydos ---
(In reply to Olof Kindgren from comment #13)
> ... we are dealing with word addresses, but are we taking that into
> consideration when we're calculating the base address?
>
> I.e. compiling an asm program
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #15 from Nick Clifton ---
(In reply to Gökçe Aydos from comment #14)
>> I.e. compiling an asm program that starts with .org 0x100, will that cause
>> the address to be set to @40 when using verilog-data-width=4 ?
>
> Oh, I think
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #16 from Olof Kindgren ---
>> I believe that practically no one has actually used this feature much
>> because of this bug
>
>I weakly remember that someone from the RISC-V community community hacked
>their own C program to conve
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #17 from Nick Clifton ---
(Sorry for the delay in replying - I have been distracted by other work).
I think that we can avoid the alignment problem by insisting that for
widths greater than one, the section(s) being converted must
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Nick Clifton changed:
What|Removed |Added
Attachment #14438|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #19 from Gökçe Aydos ---
Thanks 🎈
The address generation for data-width>1 looks fine in general. I found the
following issues:
1) Output is wrong if data-width>16. Test cases:
data-width=1:
```
@8000
B7 C0 ED FE 93 80 D0 EA
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #20 from Nick Clifton ---
(In reply to Gökçe Aydos from comment #19)
Hi Gökçe,
> 1) Output is wrong if data-width>16.
Does the verilog memory file format actually support widths greater than 16 ?
(I have never used it, so maybe
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #21 from Olof Kindgren ---
Thanks for keeping working on this. I'm afraid I haven't had any time to test
it myself but it looks like we're on the right track. Yes, the data can be as
wide as it needs to be. There's probably some up
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #22 from Gökçe Aydos ---
I browsed LRM section 21.4 about `$readmemh`, but could not find any info about
maximum width (for a memory line that is read by `$readmemh`). I think the
range is limited by the maximum width of a vector (
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Nick Clifton changed:
What|Removed |Added
Attachment #14470|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #24 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Nick Clifton :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6ef35c04dffe685ece08212201c4c032baf8aa86
commit 6ef35c04dffe685ece08212201
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Michael Platzer changed:
What|Removed |Added
CC||michael.platzer at hotmail dot
com
https://sourceware.org/bugzilla/show_bug.cgi?id=25202
Alan Modra changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
27 matches
Mail list logo
