https://sourceware.org/bugzilla/show_bug.cgi?id=32915
Jan Beulich changed:
What|Removed |Added
CC||rearnsha at sourceware dot org
--- Comm
https://sourceware.org/bugzilla/show_bug.cgi?id=32915
Jan Beulich changed:
What|Removed |Added
Target||arm-*-*
--
You are receiving this mail
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
With -march=all (or -mcpu=all) the assembler refuses use of ".arch_extension
dotprod", claiming "not allowed for the current base architecture".
".arch_e
https://sourceware.org/bugzilla/show_bug.cgi?id=32732
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32732
--- Comment #9 from Jan Beulich ---
Before marking this resolved, I wonder if the change should be cherry-picked
onto the 2.44 branch (there's likely little point in also putting it on the
2.43 one). Nick?
--
You are receiving this mail beca
https://sourceware.org/bugzilla/show_bug.cgi?id=32732
--- Comment #6 from Jan Beulich ---
See https://sourceware.org/pipermail/binutils/2025-March/140249.html for a
hopefully close-to-final patch. Ideally also give it a(nother) try.
--
You are receiving this mail because:
You are on the CC list
https://sourceware.org/bugzilla/show_bug.cgi?id=32732
--- Comment #4 from Jan Beulich ---
(In reply to Nick Clifton from comment #3)
> The intention was to allow objcopy's --section-alignment option to not only
> set the SectionAlignment field in the PE format's optional header but to
> also set
|NEW
Last reconfirmed||2025-03-10
CC||jbeulich at suse dot com
--- Comment #2 from Jan Beulich ---
In the course of trying to adapt the testcase that the original patch added, to
fit the (vaguely) change
https://sourceware.org/bugzilla/show_bug.cgi?id=32613
Jan Beulich changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
--- Comment #15 from Jan Beulich ---
(In reply to H.J. Lu from comment #13)
> Do you truly believe that R_386_GOT32 is mishandled by ld?
Why "believe"? You've demonstrated it (part of the problems, that is) to
yourself and everyone else in co
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
Jan Beulich changed:
What|Removed |Added
Status|WAITING |NEW
Component|gas
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
--- Comment #10 from Jan Beulich ---
I'm going solely from the output shown in patch 5. The first of the two VPERMB
clearly looks wrong in the linked executable. I may be missing something, as
I'm certainly aware of the conditional around the
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
--- Comment #8 from Jan Beulich ---
(In reply to H.J. Lu from comment #7)
> Were you saying that ld was OK, but as generated wrong binary?
No, the other way around: According to comment 5 gas generated a correct object
file, but ld silently b
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
--- Comment #16 from Jan Beulich ---
(In reply to H.J. Lu from comment #15)
> (In reply to Jan Beulich from comment #14)
> > (In reply to H.J. Lu from comment #13)
> > > I created a testcase which generates a linker error
> > >
> > > failed t
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
Jan Beulich changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Jan Beulich --
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
Jan Beulich changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #14 from Jan Beulich -
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
--- Comment #4 from Jan Beulich ---
Created attachment 15909
--> https://sourceware.org/bugzilla/attachment.cgi?id=15909&action=edit
annotated source file
See commentary in there. Is there anything else you need?
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
--- Comment #3 from Jan Beulich ---
(In reply to H.J. Lu from comment #2)
> If you google "i386 psABI", you should find an entry:
>
> x86 psABIs
>
> System V Application Binary Interface Processor Supplements for i386 and
> x86-64.
I did fi
https://sourceware.org/bugzilla/show_bug.cgi?id=32624
Jan Beulich changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Where in the psABI is all the special casing spelled out that was implemented
in the context of pr20244, pr21168, and pr21285? Since it's not documented
anywhere
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
--- Comment #11 from Jan Beulich ---
(In reply to H.J. Lu from comment #10)
> Please try it on Xen.
I don't see why I would put time into doing so. As previously indicated, Xen
expects .got to be empty. I don't see how that could be achieved
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
--- Comment #9 from Jan Beulich ---
(In reply to H.J. Lu from comment #8)
> My patch doesn't support fallback which is very intrusive with few benefits.
Well, as said in the original report, in the Xen project it's the fallback we'd
really ne
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
--- Comment #7 from Jan Beulich ---
You say "estimate", and since you exclude linker created sections it looks like
it very much is just an estimate. While for the specific case of Xen this may
be sufficient (see below though), in the general
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Documentation specifically says "One might use this to add OS-specific CFI
opcodes, or generic CFI opcodes that GAS does not yet support." With many
DW_CFA_* taking LEB128 operands,
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
LD appears to assume that @gotpcrel can only be used in small model or x32
code, building upon addresses of resolved symbols being within the low 4Gb (or
within ±2Gb for PIC code
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
Jan Beulich changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32579
Jan Beulich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32579
Jan Beulich changed:
What|Removed |Added
CC|jbeulich at suse dot com |
Assignee|unassigned
https://sourceware.org/bugzilla/show_bug.cgi?id=32552
--- Comment #1 from Jan Beulich ---
(In reply to Jens Remus from comment #0)
> A) Add an .eh_frame section size test to the if-condition, so that the
>FDE start field is not filled in when the FDE got discarded.
If such a check would be j
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #31 from Jan Beulich ---
Generally these have their file alignment inferred from section alignment as
well. Since they're internally generated, we don't have to "fear" huge
alignment. Hence why I had aimed at leaving their handling
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #29 from Jan Beulich ---
As I'm unable to repro this myself (issue doesn't surface on x86 hardware), can
someone who is able to please give
https://sourceware.org/pipermail/binutils/2025-January/138412.html
a try in a Linux tree
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #27 from Jan Beulich ---
(In reply to Nick Clifton from comment #26)
> Would passing bed->s->log_file_align instead of 0 have a large impact on
> object file size ? (My guess is that it would not unless the object file
> has a ver
https://sourceware.org/bugzilla/show_bug.cgi?id=30919
Bug 30919 depends on bug 31887, which changed state.
Bug 31887 Summary: gas confuses an memory operand as immediate value (no
diagnostic) for various x86 opcodes
https://sourceware.org/bugzilla/show_bug.cgi?id=31887
What|Remove
https://sourceware.org/bugzilla/show_bug.cgi?id=31887
Jan Beulich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #25 from Jan Beulich ---
(In reply to Andreas Schwab from comment #24)
> The target has no relevance when the host is reading the section contents.
I'm confused; it would help if you provided some more detail of what exactly
your
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #23 from Jan Beulich ---
(In reply to Andreas Schwab from comment #21)
> This is wrong in a cross environment. Alignment requirements differ between
> host and target.
Was my understanding then wrong that bed->s->log_file_align d
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #22 from Jan Beulich ---
(In reply to Nick Clifton from comment #20)
> Plus, if I have read Jan's v2 patch correctly, sections in object files will
> still be aligned, but just aligned to the architecture's minimum file
> alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #18 from Jan Beulich ---
(In reply to Eric Botcazou from comment #17)
> Then such a concern should have been sufficient to block the change.
Well, no, we don't really want to leave bugs around just to account for bugs
elsewhere. A
||2024-12-27
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Jan Beulich ---
I will look into this; seeing that things work correctly for J, this surely
should also be the case
https://sourceware.org/bugzilla/show_bug.cgi?id=31886
Jan Beulich changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://sourceware.org/bugzilla/show_bug.cgi?id=30919
Bug 30919 depends on bug 31886, which changed state.
Bug 31886 Summary: gas allows incorrect memory size directive for some x86
opcodes
https://sourceware.org/bugzilla/show_bug.cgi?id=31886
What|Removed |Add
https://sourceware.org/bugzilla/show_bug.cgi?id=31885
Jan Beulich changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #16 from Jan Beulich ---
(In reply to Eric Botcazou from comment #12)
> Ouch. What was the purpose of this change? Changing such an old behavior
> for no clear benefits beyond saving a few bytes looks rather questionable.
> Was
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #11 from Jan Beulich ---
(In reply to Eric Botcazou from comment #10)
> > It doesn't need to be Arm32-specific ones. Such a .rodata -> .rodata.str.*
> > conversion looks pretty generic. Just that I'm unaware of anything along
> > t
||jbeulich at suse dot com
Resolution|FIXED |---
--- Comment #12 from Jan Beulich ---
(In reply to Nick Clifton from comment #9)
> I have gone ahead and applied my patch.
While I haven't fully followed the code changes yet, the two scope
https://sourceware.org/bugzilla/show_bug.cgi?id=32324
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #3 from Jan Beulich ---
(In reply to Matthias Klose from comment #2)
> I don't have any arm32 specific patches.
It doesn't need to be Arm32-specific ones. Such a .rodata -> .rodata.str.*
conversion looks pretty generic. Just that
https://sourceware.org/bugzilla/show_bug.cgi?id=32435
--- Comment #1 from Jan Beulich ---
Is this object file representative of the problem? There's exactly one anomaly
I'm observing, which is .rodata.str1.4 having an alignment of 4 but not being
4-byte aligned in the file. That shouldn't happen
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #19 from Jan Beulich ---
(In reply to Michael Matz from comment #14)
> The scrubber removes whitespace between tokens of different classes, but
> retains
> whitespace between token of same class, which sometimes makes it so that
>
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #13 from Jan Beulich ---
(In reply to Maciej W. Rozycki from comment #12)
> Where does the notion of using whitespace for argument separation in
> macro invocations (as opposed to definitions) come from?
I have no idea, and I neve
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #10 from Jan Beulich ---
(In reply to Michael Matz from comment #9)
> I fear the only non-contentious answer to all such questions is: "act in the
> same
> way as currently" :-/ I.e. try it out and emulate the behaviour.
In which
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #8 from Jan Beulich ---
(In reply to Jan Beulich from comment #5)
> Yet then documentation is unclear on whether there may be whitespace between
> the \ and the parameter name. We could of course make macro expansion skip
> whitesp
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #5 from Jan Beulich ---
(In reply to Andreas Schwab from comment #4)
> $ cat svml_d_acos2_core-sse2.S
> #define JUMPTARGET(name) *name##@GOTPCREL(%rip)
>
> .macro WRAPPER_IMPL_SSE2 callee
> call JUMPTARGET(\callee)
> .endm
> .tex
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
Jan Beulich changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32022
--- Comment #9 from Jan Beulich ---
By paying attention to the warning that I indicated would better be emitted
instead. If need be (and if nothing like that exists yet), I'm sure ld could be
taught to have behavior along the lines of the comp
https://sourceware.org/bugzilla/show_bug.cgi?id=32022
--- Comment #7 from Jan Beulich ---
(In reply to Sam James from comment #6)
> We would need a way to make it error out by default when invoked by GCC
> then, given it exposed an x86 backend issue.
I'm afraid I can't make the connection: These
https://sourceware.org/bugzilla/show_bug.cgi?id=32022
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
--- Comment #16 from Jan Beulich ---
(In reply to H.J. Lu from comment #14)
> It should be %[quote]". Will adding support for "%[string]" to existing
> --package-metadata option break anything?
You won't know until someone reports a problem.
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
--- Comment #15 from Jan Beulich ---
(In reply to Benjamin Drung from comment #6)
> That linker testcase snippet is evaluated to:
>
> --package-metadata='{"foo":"bar"}'
>
> Passing that to a shell or makefile works, because the singe quotes
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=31903
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=31903
--- Comment #2 from Jan Beulich ---
https://sourceware.org/pipermail/binutils/2024-June/134878.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31752
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=31115
--- Comment #8 from Jan Beulich ---
(In reply to Nick Clifton from comment #5)
> > There's another thing I just discovered : I can reproduce GDB's bad
> > behavior on an ELF executable (produced by GCC from the .S file), but
> > not on a .o fi
https://sourceware.org/bugzilla/show_bug.cgi?id=31388
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=31319
--- Comment #4 from Jan Beulich ---
(In reply to Sergei Trofimovich from comment #3)
> Aha, adapting kexec-tools sounds fine as well.
>
> Does the `.code16` use look fine in the rest of the file?
They're all okay, as there's no other .arch d
https://sourceware.org/bugzilla/show_bug.cgi?id=31319
Jan Beulich changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=31178
Jan Beulich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=31178
--- Comment #5 from Jan Beulich ---
https://sourceware.org/pipermail/binutils/2024-January/131582.html
--
You are receiving this mail because:
You are on the CC list for the bug.
at sourceware dot org |jbeulich at suse dot com
--- Comment #4 from Jan Beulich ---
I can see what I overlooked (the C attribute aliases StaticRounding); working
on a fix.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31043
--- Comment #4 from Jan Beulich ---
(In reply to Sam James from comment #3)
> (In reply to Jan Beulich from comment #2)
> > Hmm, both in 2.41 and in master I'm seeing "operand size mismatch", not
> > "unsupported instruction". That's still not
https://sourceware.org/bugzilla/show_bug.cgi?id=31043
--- Comment #2 from Jan Beulich ---
Hmm, both in 2.41 and in master I'm seeing "operand size mismatch", not
"unsupported instruction". That's still not ideal, but imo quite a bit better.
Yet I'm at a loss to explain why I would see a different
https://sourceware.org/bugzilla/show_bug.cgi?id=30722
--- Comment #15 from Jan Beulich ---
(In reply to Nick Clifton from comment #14)
> Except that in such a scenario the linker will still have executed correctly.
> The fact that the v4 marker was found in a system object file rather than a
> te
https://sourceware.org/bugzilla/show_bug.cgi?id=30722
--- Comment #13 from Jan Beulich ---
While I can't say it has become entirely clear to me, it looks as if our
testcase expectations, to some degree, depend on properties of the underlying
platform. Perhaps that's a mistake that wants addressin
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
Jan Beulich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #8 from Jan Beulich ---
https://sourceware.org/pipermail/binutils/2023-September/129587.html
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #7 from Jan Beulich ---
(In reply to Antoni Boucher from comment #6)
> Do you mean that gcc produces invalid asm when using the Intel syntax and
> should be using pushq?
No. "push offset ..." is the correct form in Intel syntax. W
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
--- Comment #5 from Jan Beulich ---
(In reply to Antoni Boucher from comment #4)
> I attached the ATT version (produced by gcc) that still works.
Well, only partly: PUSHQ works, but PUSH (no suffix) doesn't according to my
testing.
--
You a
https://sourceware.org/bugzilla/show_bug.cgi?id=30856
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
Ever
https://sourceware.org/bugzilla/show_bug.cgi?id=28231
Jan Beulich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30703
--- Comment #4 from Jan Beulich ---
(In reply to Nick Clifton from comment #3)
> So the next question is - are you asking that commit 8bb23cdbb498 be
> reverted, so that the docs will build with older versions of texinfo,
> or that the t
https://sourceware.org/bugzilla/show_bug.cgi?id=28231
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
: binutils
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
MASM-generated COFF objects are copied successfully by objcopy, but at least
.text and .data are zero-padded to the next 16-byte boundary. Imo section
contents and
https://sourceware.org/bugzilla/show_bug.cgi?id=30703
--- Comment #2 from Jan Beulich ---
(In reply to Nick Clifton from comment #1)
> What is the minimum version now required ?
I don't know. My vague recollection from the earlier mail thread is that the
author of that patch also didn't really k
https://sourceware.org/bugzilla/show_bug.cgi?id=11601
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=28909
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
Jan Beulich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
onent: binutils
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
As was pointed out on the list, commit 8bb23cdbb498 raises the minimum makeinfo
version required, yet top-level configure.ac continues to be happy with 4.7,
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
--- Comment #2 from Jan Beulich ---
Created attachment 15015
--> https://sourceware.org/bugzilla/attachment.cgi?id=15015&action=edit
tentative fix
(still pending testing results, especially for the testsuite additions)
--
You are receivin
https://sourceware.org/bugzilla/show_bug.cgi?id=30688
Jan Beulich changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30578
Jan Beulich changed:
What|Removed |Added
Last reconfirmed||2023-07-20
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Attachment #14842|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Last reconfirmed||2023-04-20
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
--- Comment #3 from Jan Beulich ---
Created attachment 14842
--> https://sourceware.org/bugzilla/attachment.cgi?id=14842&action=edit
tentative fix
I'm afraid this is a result of a misuse of .eqv, which previously went
un-diagnosed by mistak
https://sourceware.org/bugzilla/show_bug.cgi?id=30292
Jan Beulich changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30248
Jan Beulich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://sourceware.org/bugzilla/show_bug.cgi?id=30317
Jan Beulich changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://sourceware.org/bugzilla/show_bug.cgi?id=30248
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment
1 - 100 of 174 matches
Mail list logo
