[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
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 greater than 1, then each word in the pattern file becomes something else
> than a byte. From the 2017 Systemverilog LRM:
>
>> 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 "word" ?
> This means for example:
> ```
> $ riscv64-elf-objcopy my.elf -O verilog --verilog-data-width=4 my.hex
> --verilog-data-endianness=input
> $ head -2 my.hex
> @8000
> FEEDC0B7 EAD08093 FF76E137 F5610113
> ```
>
> If I load these data using `$readmemh`, then `FEEDC0B7` is stored at address
> `8000_` (which is correct), but `EAD08093` is stored at `8000_0001`
> instead of `8000_0004`:
But isn't this a problem with how you are using the my.hex file ? If it has
been created with a data width of 4, then the expectation is that it will be
loaded using a mechanism that advances the address by 4 after each reading
each group of 4 bytes ? So if you want to use `$readmemh` in the way you have
shown, then you *have* to use --verilog-data-width=1. (Or just leave it
undefined, since a width of 1 is the default).
I admit that I am not an expert on the verilog file format, but that code in
the
BFD library that creates the output has been there for a long time, and if
widths
greater than 1 did not work, I would have expected to have seen bug reports
about
it before now...
> 2) wording: endian-ness and endianness seem to be used interchangeably.
> Wikipedia uses `endianness`
Yeah - I was never sure of the correct spelling, but now that you have
pointed it out, I can correct the sources.
> 3) I do not see any advantage of `--verilog-data-endianness={big,little}`.
> If the input was compiled for an architecture, I expect that the developer
> wants to use the output of objcopy for the same architecture (given that the
> chosen architecture works only with a single endianness).
Yeah - I was unsure about them too. But there are bi-endian architectures,
so maybe there is a need. It does seem to be a stretch however.
> Furthermore I understand that objcopy does not *want* to change the
> endianness. From the manual:
>
>> Note---objcopy is not able to change the endianness of its input files. If
>> the input format has an endianness (some formats do not), objcopy can only
>> copy the inputs into file formats that have the same endianness or which
>> have no endianness (e.g., srec). (However, see the --reverse-bytes option.)
That sentence is generally true, but I think that the verilog file format is a
special case, like the srec format.
But overall I think that I agree with you. It would be better to simplify the
patch and remove the big/little endian options. I will attach an updated
patch.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
https://sourceware.org/bugzilla/show_bug.cgi?id=25202 Nick Clifton changed: What|Removed |Added Attachment #14433|0 |1 is obsolete|| --- Comment #11 from Nick Clifton --- Created attachment 14438 --> https://sourceware.org/bugzilla/attachment.cgi?id=14438&action=edit Proposed patch Updated patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29737] strip: section attributes to indicate strip or persistent sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29737 --- Comment #7 from Nick Clifton --- (In reply to Guillermo E. Martinez from comment #6) > Agree, of course!. What will be next step to start working on it? I have started a discussion on this topic on the gun-gabi mailing list. (Unfortunately I do not seem to be able to find a URL to link to the discussion). At the moment the issue appears to be that just having two flag bits is not enough to express all the situations when a section should, or should not be stripped. But there is only a very limited number of bits available as section flags, so maybe another mechanism should be used. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] New: relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 Bug ID: 29761 Summary: relocatable linking loses some symbols Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14439 --> https://sourceware.org/bugzilla/attachment.cgi?id=14439&action=edit test case Attached is an automated test-case. Run test.sh to see the symbol is lost. Run test.sh lld to run the same test via lld, which works correctly. gold also works correctly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
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 "word" ? Simply an array of bits. In other words the memory can store data of arbitrary width at each address. You have the freedom. > But isn't this a problem with how you are using the my.hex file ? If it has > been created with a data width of 4, then the expectation is that it will be > loaded using a mechanism that advances the address by 4 after each reading > each group of 4 bytes ? So if you want to use `$readmemh` in the way you > have > shown, then you *have* to use --verilog-data-width=1. (Or just leave it > undefined, since a width of 1 is the default). I thought that the objcopy output is for convenient data exchange between gcc and $readmemh. My hunch is: if the developer has to write a custom data importer function that can parse the '@address' lines, then they would rather write their own Verilog-objcopy with convenient features. > I admit that I am not an expert on the verilog file format, but that code in > the > BFD library that creates the output has been there for a long time, and if > widths > greater than 1 did not work, I would have expected to have seen bug reports > about > it before now... Yeah I thought about that too, when I was writing my remark :) Your point makes sense. I just started using the Verilog output, so take my comments with a grain of salt. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-11-08 --- Comment #1 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2022-November/124257.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
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 taking that into consideration when we're calculating the base address? 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 ? Generally, I think you shouldn't trust VerilogDataWith part of the verilog output too much even if it has been there for a long time. I believe that practically no one has actually used this feature much because of this bug (and https://sourceware.org/bugzilla/show_bug.cgi?id=19921 before that) so it's likely not very well tested. Liwei Ma, we can already change the base address like you asked for with --change-addresses (you can find an example here https://github.com/chipsalliance/Cores-SweRVolf/blob/master/sw/Makefile#L27) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.40 --- Comment #2 from H.J. Lu --- Fixed by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1db13039a7c410e89f00e379fe874d8532385e41 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1db13039a7c410e89f00e379fe874d8532385e41 commit 1db13039a7c410e89f00e379fe874d8532385e41 Author: H.J. Lu Date: Tue Nov 8 14:46:25 2022 -0800 ld: Always output local symbol for relocatable link PR ld/29761 * elflink.c (elf_link_output_symstrtab): Don't skip local symbol in SEC_EXCLUDE section for relocatable link. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29763] New: [docs] The user guide needs to be expanded
https://sourceware.org/bugzilla/show_bug.cgi?id=29763 Bug ID: 29763 Summary: [docs] The user guide needs to be expanded Product: binutils Version: 2.39 Status: NEW Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: ruud.vanderpas at oracle dot com Target Milestone: --- The current version of the user guide gets people going, but lacks the details needed. All the gprofng tools need to be documented. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29763] [docs] The user guide needs to be expanded
https://sourceware.org/bugzilla/show_bug.cgi?id=29763 Ruud van der Pas changed: What|Removed |Added CC||ruud.vanderpas at oracle dot com Assignee|vladimir.mezentsev at oracle dot c |ruud.vanderpas at oracle dot com |om | Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29763] [docs] The user guide needs to be expanded
https://sourceware.org/bugzilla/show_bug.cgi?id=29763 Ruud van der Pas changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29759] [display html] Support for aarch64 is needed
https://sourceware.org/bugzilla/show_bug.cgi?id=29759 Ruud van der Pas changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #4 from Stas Sergeev --- Thanks, that was quick! Interestingly, the symbol was not really excluded. It was still present in an nm output, but without a name. This makes me wonder, now, in case of a non-relocatable link when such symbol should actually be excluded, will it be excluded properly or would it just lost its name, as was seen here? -- You are receiving this mail because: You are on the CC list for the bug.
