[Bug gas/12240] offset can't be used as label in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=12240 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53929 CC||pinskia at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30418] use of labels that happen to match register names or keywords
https://sourceware.org/bugzilla/show_bug.cgi?id=30418 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53929 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30418] use of labels that happen to match register names or keywords
https://sourceware.org/bugzilla/show_bug.cgi?id=30418 LIU Hao changed: What|Removed |Added Target|x86-64-*-* |x86_64-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30418] use of labels that happen to match register names or keywords
https://sourceware.org/bugzilla/show_bug.cgi?id=30418 --- Comment #2 from LIU Hao --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109726 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30418] use of labels that happen to match register names or keywords
https://sourceware.org/bugzilla/show_bug.cgi?id=30418 LIU Hao changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from LIU Hao --- I'm gonna file another report to GCC for removal of the explicit RIP and bracket. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30418] use of labels that happen to match register names or keywords
https://sourceware.org/bugzilla/show_bug.cgi?id=30418 LIU Hao changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=12240 Target||x86-64-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30418] New: use of labels that happen to match register names or keywords
https://sourceware.org/bugzilla/show_bug.cgi?id=30418
Bug ID: 30418
Summary: use of labels that happen to match register names or
keywords
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Possible dup of https://sourceware.org/bugzilla/show_bug.cgi?id=12240
This is how MSVC handles such names:
(https://gcc.godbolt.org/z/TonjYaxqj)
```
static int* volatile rip;
static unsigned int volatile eax;
int
get_value(void)
{
return rip[eax];
}
```
MSVC outputs:
```
get_value PROC ; COMDAT
mov ecx, DWORD PTR eax
mov rax, QWORD PTR rip
mov eax, DWORD PTR [rax+rcx*4]
ret 0
get_value ENDP
```
GCC outputs:
```
get_value:
mov rdx, QWORD PTR rip[rip]
mov eax, DWORD PTR eax[rip]
mov eax, DWORD PTR [rdx+rax*4]
ret
```
In the case of MSVC, `DWORD PTR eax` is unambiguously parsed as the label `eax`
and `DWORD PTR [eax]` is unambiguously parsed as the register `eax`. The
address of all labels are always relative to RIP, but it is implied, and
brackets are not written explicitly.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354 --- Comment #6 from Hans-Peter Nilsson --- (In reply to Torbjörn SVENSSON from comment #5) > I don't know if there has been any other cleanup lately in ld, but it looks > like the elf size is much smaller with ld from master than > 5c0b4ee406035917d0e50aa138194fab57ae6bf8 that was used in the Arm GCC > 11.3.rel1 release. Is it expected that the elf size for the demo application > would drop from ~203kB to ~31kB? Note that the size of text and data > sections are still the same. Perhaps it's 1a26a53a0dee. You're welcome. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #10 from Pali Rohár --- Checking IMAGE_SCN_MEM_DISCARDABLE is not a good idea too as this section is still loaded from .sys drivers and discarded after driver is initialized. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30300] LTO drops entry point symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=30300 --- Comment #3 from Pali Rohár --- Do you need some more testing? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354 --- Comment #5 from Torbjörn SVENSSON --- (In reply to Nick Clifton from comment #4) > Please could you try out this patch and let me know if it works for you ? I've played a bit with this patch now and indeed the debug symbols are preserved, but the binary is also much smaller than before. Just looking at the patch, I'm a bit confused about the variable "extra_marks_added". The initial value is true, and in the function body, it's set to true in certain cases, but it's never set to false and thus, the if-statement at the end of the patch should always happen. Is this the desired behavior? I don't know if there has been any other cleanup lately in ld, but it looks like the elf size is much smaller with ld from master than 5c0b4ee406035917d0e50aa138194fab57ae6bf8 that was used in the Arm GCC 11.3.rel1 release. Is it expected that the elf size for the demo application would drop from ~203kB to ~31kB? Note that the size of text and data sections are still the same. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25694] R_RISCV_TPREL_HI20 relocations cause riscv64 to add TEXTREL bit on executables
https://sourceware.org/bugzilla/show_bug.cgi?id=25694
Nelson Chu changed:
What|Removed |Added
CC||nelsonc1225 at sourceware dot
org
--- Comment #4 from Nelson Chu ---
Haven't test these changes for the riscv-gnu-toolchain regressions, and not yet
test for other project. However, at least TLS LE testcase mentioned here, and
the pr22263-1 testcase looks good after applying the following changes.
For the R_RISCV_TPREL_HI20 in check_reloc, not really sure why we used to goto
static_reloc when pie/pde. Refer to spare and loongarch, it's just pass and
won't reserve local dynamic reloc for TLS LE in pie/pde, and similar for other
targets. So we probably too conservative before.
As for the TLS GD/IE in riscv_elf_relocate_section, I refer to what Maciej did
for pr22570, commits 9143e72c6d4d and 1cb83cac9a89, seems also the right way to
do the same thing for risc-v.
diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
index 77a732b6a08..bbb5d0cd5ff 100644
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -824,7 +824,7 @@ riscv_elf_check_relocs (bfd *abfd, struct bfd_link_info
*info,
break;
case R_RISCV_TLS_GOT_HI20:
- if (bfd_link_pic (info))
+ if (bfd_link_dll (info))
info->flags |= DF_STATIC_TLS;
if (!riscv_elf_record_got_reference (abfd, info, h, r_symndx)
|| !riscv_elf_record_tls_type (abfd, h, r_symndx, GOT_TLS_IE))
@@ -920,11 +920,12 @@ riscv_elf_check_relocs (bfd *abfd, struct bfd_link_info
*info,
goto static_reloc;
case R_RISCV_TPREL_HI20:
+ /* This is not allowed in the pic, but okay in pie. */
if (!bfd_link_executable (info))
return bad_static_reloc (abfd, r_type, h);
if (h != NULL)
riscv_elf_record_tls_type (abfd, h, r_symndx, GOT_TLS_LE);
- goto static_reloc;
+ break;
case R_RISCV_HI20:
if (bfd_link_pic (info))
@@ -2797,24 +2798,20 @@ riscv_elf_relocate_section (bfd *output_bfd,
if (htab->elf.srelgot == NULL)
abort ();
- if (h != NULL)
- {
- bool dyn, pic;
- dyn = htab->elf.dynamic_sections_created;
- pic = bfd_link_pic (info);
-
- if (WILL_CALL_FINISH_DYNAMIC_SYMBOL (dyn, pic, h)
- && (!pic || !SYMBOL_REFERENCES_LOCAL (info, h)))
- indx = h->dynindx;
- }
+ bool dyn = elf_hash_table (info)->dynamic_sections_created;
+ if (h != NULL
+ && h->dynindx != -1
+ && WILL_CALL_FINISH_DYNAMIC_SYMBOL (dyn, bfd_link_pic (info),
h)
+ && (bfd_link_dll (info) || !SYMBOL_REFERENCES_LOCAL (info,
h)))
+ indx = h->dynindx;
/* The GOT entries have not been initialized yet. Do it
now, and emit any relocations. */
- if ((bfd_link_pic (info) || indx != 0)
+ if ((bfd_link_dll (info) || indx != 0)
&& (h == NULL
|| ELF_ST_VISIBILITY (h->other) == STV_DEFAULT
|| h->root.type != bfd_link_hash_undefweak))
- need_relocs = true;
+ need_relocs = true;
if (tls_type & GOT_TLS_GD)
--
You are receiving this mail because:
You are on the CC list for the bug.
