||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
https://sourceware.org/bugzilla/show_bug.cgi?id=30690
Jose E. Marchesi changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: 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
|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.
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.
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 muti
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
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 f
|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.
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 charac
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.
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
https://sourceware.org/bugzilla/show_bug.cgi?id=30444
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29757
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=29728
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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:
||.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.
: 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.
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".
>
> W
https://sourceware.org/bugzilla/show_bug.cgi?id=29728
Jose E. Marchesi changed:
What|Removed |Added
CC||guillermo.e.martinez@oracle
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
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
|--- |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 t
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
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 --g
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 th
https://sourceware.org/bugzilla/show_bug.cgi?id=21407
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
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.
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.
___
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
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
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
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 t
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
https://sourceware.org/bugzilla/show_bug.cgi?id=19019
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
35 matches
Mail list logo
