[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #3 from Jose E. Marchesi --- The SCD in page 4P-3 declares that the purpose of STT_SPARC_REGISTER is to indicate the "Usage of a global register reserved by the application" and, optionally, global registers reserved for system software. The subset of global registers reserved for applications is defined in page 3P-10 as %g2 and %g3. Likewise, the subset of global registers reserved for system software is defined in the same table. So I think that the BFD check is pertinent and matches the ABI. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #4 from Jose E. Marchesi --- $ readelf -s libsystemd.so.0.11.0 [...] 617: 0 REGISTER GLOBAL DEFAULT UND There it is... st_value is 0. How was this library linked, exactly? I tried to build systemd 226 in my non-Debian sparc64 system, but gave up due to many build errors... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #6 from Jose E. Marchesi --- This could still be a bug in either binutils or GCC. However, I have bootstrapped GCC 5 (also svn trunk GCC) with the latest binutils in sparc64 and have never seen this issue. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #8 from Jose E. Marchesi --- libsystemd.so.0.3.1 contains the expected STT_SPARC_REGISTER entries, for %g2 and %g3: 4: 0002 0 REGISTER GLOBAL DEFAULT UND 5: 0003 0 REGISTER GLOBAL DEFAULT UND -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #14 from Jose E. Marchesi --- The latest version of the psABI is sparc.org/wp-content/uploads/2014/01/SCD.2.4.1.pdf.gz for 64 bits, and psABI31 for 32 bits. These are old, so you can basically ignore the "experimental" remarks. I am working internally at Oracle to get the psABI updated, expanded (it is time, right :)) and unified in a single document. So, lacking a normative reference I would basically mimic what ld/bfd does to handle STT_REGISTER symbols. There are several hooks in BFD used by ld to add and merge that stuff. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #16 from Jose E. Marchesi --- Looks like davem already tried to add proper support for STT_REGISTER to gold: https://sourceware.org/ml/binutils/2008-04/msg00286.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #17 from Jose E. Marchesi --- Cary, are you still working on this issue? Otherwise I will jump in and try to hack the needed support in gold... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #19 from Jose E. Marchesi --- Hi Cary. Any progress on this? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21407] gas -relax option on SPARC generates incorrect code
https://sourceware.org/bugzilla/show_bug.cgi?id=21407 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #1 from Jose E. Marchesi --- Hi Jeremy. I cannot reproduce the issue with latest git binutils (nor with an old binutils 2.20) in sparc64-linux-gnu, so this seems to be Solaris specific. Anyway, I would expect for the relaxation to not happen when the value of the symbol is not known at assemble time (addsy is not NULL) as there is no way for the assembler to determine whether the branch distance will fall within the narrower limits of the branch instructions after resolution. If the relaxation happens, the fixup is fully resolved in md_apply_fix, and no relocation is generated by the assembler. I will try to reproduce the problem in a solaris machine. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21407] gas -relax option on SPARC generates incorrect code
https://sourceware.org/bugzilla/show_bug.cgi?id=21407 --- Comment #2 from Jose E. Marchesi --- Ok, sparc-sun-sunos4.1.3 is an a.out target, not an ELF one. That explains why the check on addsy!=NULL doesn't happen. Investigating further... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21407] gas -relax option on SPARC generates incorrect code
https://sourceware.org/bugzilla/show_bug.cgi?id=21407
--- Comment #3 from Jose E. Marchesi ---
My conclusion is that the real bug here is that GAS relaxes the CALL
instruction even if the fixup can't be fully resolved in md_apply_fix. This
only happens in a.out targets.
This fixes it:
diff --git a/gas/config/tc-sparc.c b/gas/config/tc-sparc.c
index 030e10d..c6b4476 100644
--- a/gas/config/tc-sparc.c
+++ b/gas/config/tc-sparc.c
@@ -3585,7 +3585,8 @@ md_apply_fix (fixS *fixP, valueT *valP, segT segment
ATTRIBUTE_UNUSED)
insn |= val & 0x3fff;
/* See if we have a delay slot. */
- if (sparc_relax && fixP->fx_where + 8 <= fixP->fx_frag->fr_fix)
+ if (sparc_relax && !fixP->fx_addsy
+ && fixP->fx_where + 8 <= fixP->fx_frag->fr_fix)
{
#define G0 0
#define O7 15
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21407] gas -relax option on SPARC generates incorrect code
https://sourceware.org/bugzilla/show_bug.cgi?id=21407 --- Comment #5 from Jose E. Marchesi --- When md_apply_fix is called, the fixup information for relocations that can be already resolved by patching constants in instructions (like symbols defined in the same segment in a.out) has addsy set to NULL instead of containing information about a symbol or a segment symbol. Take a look to gas/write.c:fixup_segment. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21407] gas -relax option on SPARC generates incorrect code
https://sourceware.org/bugzilla/show_bug.cgi?id=21407 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at sourceware dot org |jose.marchesi at oracle dot com --- Comment #10 from Jose E. Marchesi --- Ok, despite Nick's spamming attempt ;) I am resolving this issue as fixed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/29728] New: bpf: support LLVM BPF pseudo-C assembly syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=29728 Bug ID: 29728 Summary: bpf: support LLVM BPF pseudo-C assembly syntax Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jose.marchesi at oracle dot com Target Milestone: --- The GNU assembler supports a conventional syntax for BPF assembly. This contrasts with the BPF LLVM backend, which uses a bizarre pseudo-C syntax (assignments for `mov' instructions, goto statements for branch instructions, etc). While we don't want to abandon the conventional assembly syntax (it has a lot of advantages, like for example proper integration in debuggers, disassemblers, etc that, well, expect an assembly-like syntax in assembly languages) this divergence with LLVM is a blocker, since kernel headers contain inline `asm' instructions that use the pseudo-C syntax. So this bugzilla is for adding support for the pseudo-C assembly BPF syntax to the GNU assembler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29728] bpf: support LLVM BPF pseudo-C assembly syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=29728 Jose E. Marchesi changed: What|Removed |Added Assignee|unassigned at sourceware dot org |jose.marchesi at oracle dot com --- Comment #2 from Jose E. Marchesi --- (In reply to Nick Clifton from comment #1) > (In reply to Jose E. Marchesi from comment #0) > > > So this bugzilla is for adding support for the pseudo-C assembly BPF syntax > > to the GNU assembler. > > Is there a specification for this syntax ? AFAIK, no. It is basically "what LLVM parses". > Also - given that you are the maintainer for the BPF port, will you be > assigning this PR to yourself ? Yep I just did that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29728] bpf: support LLVM BPF pseudo-C assembly syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=29728 Jose E. Marchesi changed: What|Removed |Added CC||guillermo.e.martinez@oracle ||.com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29728] bpf: support LLVM BPF pseudo-C assembly syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=29728 --- Comment #4 from Jose E. Marchesi --- (In reply to Nick Clifton from comment #3) > (In reply to Jose E. Marchesi from comment #2) > > >> Is there a specification for this syntax ? > > AFAIK, no. It is basically "what LLVM parses". > > Well that sounds bad. Can you talk to the LLVM community about this ? A > proper specification is pretty much essential for compatibility to work. I will. However, to be fair on that topic, how many of the assembly language syntax supported by GAS are formally specified? Our own BPF assembly syntax certainly isn't. (I think it may be possible to generate documentation for it using CGEN. Never tried though.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29757] New: bpf: document assembly syntax in the manual
https://sourceware.org/bugzilla/show_bug.cgi?id=29757 Bug ID: 29757 Summary: bpf: document assembly syntax in the manual Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: jose.marchesi at oracle dot com Reporter: jose.marchesi at oracle dot com Target Milestone: --- The syntax understood by the BPF assembler shall be documented in the GAS manual. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29954] bpf sim tests fail due to linker triggering LOAD segment with RWX permissions test by default
https://sourceware.org/bugzilla/show_bug.cgi?id=29954 Jose E. Marchesi changed: What|Removed |Added CC||guillermo.e.martinez@oracle ||.com Assignee|unassigned at sourceware dot org |jose.marchesi at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29954] bpf sim tests fail due to linker triggering LOAD segment with RWX permissions test by default
https://sourceware.org/bugzilla/show_bug.cgi?id=29954 --- Comment #2 from Jose E. Marchesi --- Hi Nick. I tried that locally and definitely works. But I don't think it is the right fix in this case. When linked without -Ttext=0x0, the following segments are created in the resulting executable: Elf file type is EXEC (Executable file) Entry point 0x40 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align LOAD 0x0010 0x0040 0x0040 0x0648 0x0648 R E0x10 LOAD 0x00101648 0x00801648 0x00801648 0x0006 0x0006 RW 0x10 Section to Segment mapping: Segment Sections... 00 .text 01 .data Which is perfectly fine. But then it is the simulator that fails with: spawn ./bpf/run --memory-size=4Mb /home/jemarch/gnu/src/binutils-gdb/build-bpf/sim/alu.s.x core: 8 byte read to unmapped address 0x40 at 0x40 Meaning the simulator is somehow not loading the segments at the right VMA. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29728] bpf: support LLVM BPF pseudo-C assembly syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=29728 Jose E. Marchesi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jose E. Marchesi --- This is now implemented in the assembler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29757] bpf: document assembly syntax in the manual
https://sourceware.org/bugzilla/show_bug.cgi?id=29757 Jose E. Marchesi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- The BPF GAS manual has been expanded to document the alternate assembly syntax. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #1 from Jose E. Marchesi --- What is the endianness of the base64 encoded integer? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #3 from Jose E. Marchesi --- Regardless of the target endianness? Is there a spec for this somewhere? Otherwise, it would be good to look at llvm's PE support and make sure the endianness is always big. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #6 from Jose E. Marchesi --- The LLVM code assumes big-endian. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #7 from Jose E. Marchesi --- While implementing this in GNU poke [1] I noticed that the base64 value encoded in ASCII after the // is mutilated, since in order to fit in six characters it is omitting the trailing two padding characters ==. [1] https://git.savannah.nongnu.org/cgit/poke.git/commit/?id=22ae5dc18877c6c086b2f4dd472ec188a3a9f90f -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2023-05-14 Assignee|unassigned at sourceware dot org |jose.marchesi at oracle dot com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #9 from Jose E. Marchesi --- Sven, could you please provide: 1) A test.S compiled from test.c. I have a x86_64-w64-mingw binutils built but not a suitable cross GCC. I will then derive testcases for binutils starting from that file. 2) A test.o built with a toolchain that is able to emit //BASE64 names. I am starting with the BFD support for reading the names. Then will implement writing support. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #11 from Jose E. Marchesi --- Oh sorry, I overlooked llvm-test.o and test.o. Yes these are in the 7z archive. Thanks. Thanks for the .s file. I believe I have now everything I need. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #12 from Jose E. Marchesi --- (In reply to Sven from comment #8) > (In reply to Jose E. Marchesi from comment #7) > > While implementing this in GNU poke [1] I noticed that the base64 value > > encoded in ASCII after the // is mutilated, since in order to fit in six > > characters it is omitting the trailing two padding characters ==. > > Yes, the padding is omitted. But according to section 3.2 of RFC 4648, the > padding is optional if so desired. Any RFC compliant decoder should work. > > Also see https://en.wikipedia.org/wiki/Base64#Variants_summary_table Ok, this is worse than I thought :) Given the section name //AAph7S, the corresponding base64 to decode is 00AAph7S, _not_ AAph7S==. Found it the hard way while implementing this in BFD. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)
https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #14 from Jose E. Marchesi --- Correct. The encoding is simple base 64 using the base64 alphabet, but not the RFC base64 encoding. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30690] bpf: relax short jumps to V4 long jumps
https://sourceware.org/bugzilla/show_bug.cgi?id=30690 Jose E. Marchesi changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |jose.marchesi at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30690] New: bpf: relax short jumps to V4 long jumps
https://sourceware.org/bugzilla/show_bug.cgi?id=30690 Bug ID: 30690 Summary: bpf: relax short jumps to V4 long jumps Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jose.marchesi at oracle dot com Target Milestone: --- The BPF assembler shall be expanded to support relaxing short (16-bit disp) jump instructions to 32-bit disp long jump instructions. The V4 BPF ISA introduces an unconditional jump instruction that uses a 32-bit displacement immediate. These relaxations are possible: Unconditional jump: ja disp16 -> jal disp32 Conditional jumps: jXX disp16 -> jXX +1; ja +1; jal disp32 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30690] bpf: relax short jumps to V4 long jumps
https://sourceware.org/bugzilla/show_bug.cgi?id=30690 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build
https://sourceware.org/bugzilla/show_bug.cgi?id=31109 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jose.marchesi at oracle dot com Last reconfirmed||2023-12-12 Ever confirmed|0 |1 --- Comment #9 from Jose E. Marchesi --- I think it is about backporting this patch from master to releases/gcc-13: commit 24552056fd5fc677c0d032f54a5cad1c4303d312 Author: Vladimir Mezentsev AuthorDate: Fri Mar 11 08:58:31 2022 + Commit: Arsen Arsenović CommitDate: Mon Aug 7 22:59:38 2023 +0200 gprofng: a new GNU profiler ChangeLog: * Makefile.def: Add gprofng module. * configure.ac: Add --enable-gprofng option. * Makefile.in: Regenerate. * configure: Regenerate. include/ChangeLog: * collectorAPI.h: New file. * libcollector.h: New file. * libfcollector.h: New file. -- You are receiving this mail because: You are on the CC list for the bug.
