[Bug binutils/28719] DWARF-5 section names in PE/PEP and weak symbols in Cygwin
https://sourceware.org/bugzilla/show_bug.cgi?id=28719 --- Comment #3 from Achim --- Created attachment 13942 --> https://sourceware.org/bugzilla/attachment.cgi?id=13942&action=edit Linker map old (ld-2.36) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28841] New: ld: Customize output section type
https://sourceware.org/bugzilla/show_bug.cgi?id=28841
Bug ID: 28841
Summary: ld: Customize output section type
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
On ELF platforms, an output section is SHT_PROGBITS by default.
https://sourceware.org/binutils/docs/ld/Output-Section-Type.html#Output-Section-Type
allows one to create a SHT_NOBITS type section.
It's useful to support an arbitrary type.
Then the user can create an output section with just data commands.
Currently there is some magic (bfd/elf.c special_sections_n recognizes `.note*`
as SHT_NOTE) which goes against the ELF spirit that attributes should be
identified as well known integers, not magic names.
% cat a.lds
SECTIONS
{
.noload (NOLOAD) : { BYTE(0) }
.info (INFO) : { BYTE(0) }
.note.package (SHT_NOTE) : { BYTE(0) } /* or .note.package (0x7) : {
BYTE(0) } */
.init_array (SHT_INIT_ARRAY) : { ... }
}
INSERT AFTER .note.gnu.build-id;
% as /dev/null -o a.o
% ld.bfd -T a.lds --build-id a.o -o a
It may be useful to customize sh_flags as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/28842] New: colon() problem in gas?
https://sourceware.org/bugzilla/show_bug.cgi?id=28842
Bug ID: 28842
Summary: colon() problem in gas?
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jacob at jacob dot remcomp.fr
Target Milestone: ---
GAS, the GNU assembler features a colon() function that creates labels. In all
versions I have seen, there is a sequence like this:
391 /* New .comm for prev .comm symbol.
392
393 If the new size is larger we just change its
394 value. If the new size is smaller, we ignore
395 this symbol. */
396 if (S_GET_VALUE (symbolP)
397 < ((unsigned) frag_now_fix ()))
398 {
399S_SET_VALUE (symbolP, (valueT) frag_now_fix ());
400 }
I am sorry, maybe I am missing something, but the code is doing THE OPPOSITE of
what the comments say.
Do you see the < sign above? Shouldn't that be a > sign???
The frag_now_fix() function is defined in frags.c:
383 addressT
384 frag_now_fix (void)
385 {
386 if (now_seg == absolute_section)
387 return abs_section_offset;
388
389 return ((char *) obstack_next_free (&frchain_now->frch_obstack)
390 - frag_now->fr_literal);
391 }
As far as I understand it, it returns the size of frag_now.
The whole is utterly incomprehensible.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/28842] colon() problem in gas?
https://sourceware.org/bugzilla/show_bug.cgi?id=28842 Andreas Schwab changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andreas Schwab --- S_GET_VALUE (symbolP) returns the current size, frag_now_fix () returns the new size. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28842] colon() problem in gas?
https://sourceware.org/bugzilla/show_bug.cgi?id=28842 --- Comment #2 from jacob at jacob dot remcomp.fr --- > Le 29 janv. 2022 à 12:36, sch...@linux-m68k.org > a écrit : > > https://sourceware.org/bugzilla/show_bug.cgi?id=28842 > > Andreas Schwab changed: > > What|Removed |Added > > Resolution|--- |NOTABUG > Status|UNCONFIRMED |RESOLVED > > --- Comment #1 from Andreas Schwab --- > S_GET_VALUE (symbolP) returns the current size, frag_now_fix () returns the > new > size. > OK, thanks for your explanation. The whole base of free software relies on people trying to read (and understand) the code. I am sorry if I bother you, and I thank you for your (very fast) answer > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28843] New: regression: readelf -n became slow without -wN
https://sourceware.org/bugzilla/show_bug.cgi?id=28843 Bug ID: 28843 Summary: regression: readelf -n became slow without -wN Product: binutils Version: 2.37 Status: NEW Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jan at jankratochvil dot net Target Milestone: --- $ du -h binarywithdwarf 187Mbinarywithdwarf binutils-2.27-44.base.el7_9.1.x86_64 $ time readelf -n binarywithdwarf >/dev/null real0m0.012s binutils-2.37-10.fc35.x86_64 $ time readelf -n binarywithdwarf >/dev/null real0m7.946s $ time readelf -n -wN binarywithdwarf >/dev/null real0m0.039s Using -n to read NT_GNU_BUILD_ID. -- You are receiving this mail because: You are on the CC list for the bug.
