[Bug ld/20694] PDP11 TARGET_PAGE_SIZE is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=20694 Stephen Casner changed: What|Removed |Added Version|unspecified |2.27 -- 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 ld/20694] New: PDP11 TARGET_PAGE_SIZE is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=20694 Bug ID: 20694 Summary: PDP11 TARGET_PAGE_SIZE is incorrect Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- The file ld/emulparams/pdp11.sh includes the line: TARGET_PAGE_SIZE=256 The actual page size of the memory management hardware on the PDP11/45, PDP11/70, etc. is 8192 bytes. A consequence of this error is that the data section in a.out format output is not offset to a page boundary. I have verified that the UNIX V6 ld program running on a simulated PDP11 does offset the data section to the next page boundary (2 octal) when the -n option is included. -- 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 ld/20694] PDP11 TARGET_PAGE_SIZE is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=20694 --- Comment #3 from Stephen Casner --- Do you need assistance with bringing up 2.11BSD and UNIX v7 systems on an emulated PDP11? Those systems are included as examples prepared to run on the PiDP11/70 recreated model front panel that Oscar Vermeulen has produced that uses simh as the emulation and Blinkenbone as the communication API. I could assist with running whatever tests you would like to see. -- 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 ld/20694] PDP11 TARGET_PAGE_SIZE is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=20694 --- Comment #7 from Stephen Casner --- I have tested with a build from the git repository and concur that this bug is fixed. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25569] New: PDP11 ld -s clobbers last data byte
https://sourceware.org/bugzilla/show_bug.cgi?id=25569 Bug ID: 25569 Summary: PDP11 ld -s clobbers last data byte Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Created attachment 12294 --> https://sourceware.org/bugzilla/attachment.cgi?id=12294=edit Proposed patch When the -s option is supplied to ld for pdp11-aout target to suppress writing the symbol table, the last byte of the .data section is overwritten with 0. There is code explicitly written to do this near the end of the final_link function in bfd/pdp11.c. It appears that the intention of that code was to pad with 0 for a .data section of odd length, but the last data byte is overwritten when the length is even. Furthermore, in normal usage the length is always even because gas pads the .data section in an object file if it is odd. For testing, and odd-length .data section can be forced with a linker script that appends one byte. I am attaching a proposed fix that checks for the file length being odd using the bfd->where member and only appends the 0 pad byte in that case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20694] PDP11 TARGET_PAGE_SIZE is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=20694 --- Comment #6 from Stephen Casner --- Thanks for making this fix. I can’t do any testing immediately but will do so in a couple of weeks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] New: Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 Bug ID: 25677 Summary: Changes to --*magic options for pdp11-aout target Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Target: pdp11-aout Created attachment 12378 --> https://sourceware.org/bugzilla/attachment.cgi?id=12378=edit Proposed enhancement This enhancement consists of two changes related to the ld magic number options. First, the default format for the pdp11-aout target should be --omagic rather than --nmagic to be consistent with the behavior of the ld programs both in Unix v6 at the beginning of Unix on the PDP11 and in 2.11 BSD at its end. That format does not page-align the .data section and generates magic number 0407 which indicates to the runtime system that the .text section should not be read-only. I've changed the default only for the pdp11 emulation. Second, I have added a new option --imagic to generate output with magic number 0411 (defined as IMAGIC in Unix v6 ld.c) that puts both the .text and .data sections starting at address 0 for loading into the separate instruction and data address spaces of larger PDP11 models. For ld on Unix v6 this format was selected with option -i, but that option already has another meaning in binutils ld. In 2.11 BSD the option -z was added as a synonym for -i, so within the pdp11 emulation I also implemented that option as a synonym for --imagic. These changes affect only the pdp11 emulation and they are implemented all within an expansion of the customization files for the pdp11 emulation except for two one-line changes in the common code as explained below. The expansion of the pdp11 customization consists of adding a pdp11.em file containing _before_parse() to adjust the default config settings consistent with --omagic. It also contains functions _add_options(), _list_options() and _handle_option() to implement the additional options including printing pdp11-specific help for all of the --*magic options. I also needed a new _get_script() function that compiles-in a sixth linker script where the .data section starts at address 0. Since genscripts does not produce such a script, when compiling-in the scripts I reuse the script that aligns the data to a page boundary but edit it to set address 0 instead. Related to this, I observe that the code in the adjust_*_magic() functions in bfd/aoutx.h and bfd/pdp11.c that sets the VMA for data is not effective because the alignment directive in the linker script overrides it. I also added a pdp11.sc file instead of using aout.sc so I could remove some sections that are extraneous for the pdp11 emulation. Comments are requested regarding the following design choices: - I have used the existing boolean ld_config_type::separate_code to indicate when --imagic is seen in the option parsing. To me its meaning seemed consistent with the new way I'm using it, but I could add another boolean if that would be preferred. - Rather than define another flag bit in bfd_target::object_flags, I'm copying the state of the separate_code boolean into a local variable in bfd/pdp11.c at _final_link() time for reference later in adjust_sizes_and_vmas() as the sections are written. - Since the --imagic format intentionally causes the .text and .data sections to occupy the same memory addresses, I had to set command_line.check_section_addresses = 0. Would that cause any other problems? - In my generated epdp11.c, the function name prefix is gldpdp11 rather than gld_pdp11 since that is how the code was written in the emulation from which I borrowed code. But I also saw the underscore included in a different emulation. Is one of these considered correct? The two one-line changes that I needed to make in common code are as follows: - I needed to add i_magic to enum aout_magic in bfd/libaout.h. - In ld/lexsup.c, I needed to set config.text_read_only to TRUE in case 'n'. This is the same as the default value of that boolean as initialized in ldmain.c so I assume my change won't affect any non-pdp11 emulation. I need this change so that my change of the default value for pdp11 will work. That boolean is initialized to FALSE or TRUE in case 'N' and case OPTION_NO_OMAGIC. I have not yet implemented changes to the documentation or test cases pending review of the code. The diff is attached. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963
Stephen Casner changed:
What|Removed |Added
CC||casner at acm dot org
--- Comment #6 from Stephen Casner ---
The test pr18963.t introduced with this update fails for the
pdp11-aout target because the source file is empty and the output file
is built entirely in the linker script. That means the file size does
not match the sizes in the a.out header, so nm cannot open the file.
I am trying a replacement test that allocates text, data and bss space
in a pr18963.s file instead, and then makes similar symbol assignments
after those sections in the linker script.
A second problem is that the output size from the existing linker
script is larger than the 16-bit address space of the pdp11, but I
believe that scaling down the sizes by a factor of 0x100 imposes no
loss of generality.
To validate my modified test script I have backed up to commit
a8aa551e5abde13e063beb32ec0366bdc6008d71 before this update and then I
built for target i386-elf32 which looks that the target in use for the
initial bug report.
I then copied pr18963.d and pr18963.t into this tree and edited
pr18963.t to remove the ASSERT so I could examine the result from nm
(in alphabetical sort):
0008 T A
0009 T B
000a D C
0007 T D
0009 D E
0008 T _start
Since D!=E this verifies a replication of the bug conditions.
Then I put in place my proposed new test consisting of source file
pr18963.s:
.globl _start
.text
_start:
.=.+0x800
.globl _data
.data
_data:
.=.+0x100
.globl _bss
.bss
_bss:
.=.+0x100
.end
Modified linker script pr18963.t using the sections from the input but
still defining the symbols outside of the sections:
SECTIONS
{
.text :
{
*(.text)
}
A = .;
.data :
{
*(.data)
}
B = .;
.bss :
{
*(.bss)
}
C = .;
D = A - C + B;
E = A + B - C;
/DISCARD/ : {*(*)}
}
And test script pr18963.d modified just by changing the source file
and scaling down by 0x100:
# source: pr18963.s
# ld: -T pr18963.t
# nm: -B -n
#...
0+700 A D
#...
0+700 A E
#...
0+800 T A
#...
0+900 D B
#...
0+a00 B C
#pass
The result result from nm (again in alphabetical sort) is:
0800 T A
0900 D B
0a00 B C
0700 D D
1900 B E
0900 B _bss
0800 D _data
T _start
I see that D = 0x700 (as expected by scaling the 0x7 result from
the original linker script by 0x100) but E = 0x1900 rather than 0x900
(the original linker script result was 0x9). I don't have an
explanation for that difference, but I do see that E is relocated to
bss rather than to data as in the result from the original linker
script.
My revised test passes for both i386-elf32 and pdp11-aout with the
current source tree. Would you accept it as a replacement (with the
ASSERT put back in)? If so, I will prepare a patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #11 from Stephen Casner --- Created attachment 12448 --> https://sourceware.org/bugzilla/attachment.cgi?id=12448=edit Completed patch including tests and doc Here is a patch against a current git pull that I believe includes all of the requested changes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #8 from Stephen Casner --- Created attachment 12461 --> https://sourceware.org/bugzilla/attachment.cgi?id=12461=edit Patch for test to work with pdp11-aout I found that my proposed pr18963.s got an assembly error with target cris-aout because pseudo-op .bss is not defined. So I changed to use .lcomm instead, and removed the _data and _bss symbols that were not needed, then the output is the same as for the old script except for the different value for E and different section associations for some symbols. With the revised pr18963.s the test passes with targets x86_64-linux-gnu, i386-elf32, cris-aout, z80-coff and pdp11-aout. I believe the attached patch is complete for commit. Suggested log: Fix test ld-scripts/pr18963 to work on targets such as pdp11-aout where having the linker script modify the section sizes causes the output format to be invalid. Also reduce the size of the test addresses to fit in 16-bits. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #9 from Stephen Casner --- (In reply to Stephen Casner from comment #8) ... > the output is the same as for the old script except for the different value > for E and different section associations for some symbols. To clarify, those differences are when running the test script against commit a8aa551e5abde13e063beb32ec0366bdc6008d71 from before the code change, as described near the end of comment 6. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 --- Comment #1 from Stephen Casner --- Created attachment 12464 --> https://sourceware.org/bugzilla/attachment.cgi?id=12464=edit Patch for configure Add gdb and gprof to noconfigdirs for pdp11-*-*; gdbserver is handled separately by not including a configuration for pdp11 in configure.srv. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 --- Comment #1 from Stephen Casner --- Created attachment 12463 --> https://sourceware.org/bugzilla/attachment.cgi?id=12463=edit Patch to fix tests After the patch for reopened PR 18963 and the patch for PR 25828 and this patch are applied the ld testsuite will run for target pdp11-aout with no unexpected failures (also no failures introduced by these patches for targets x86_64-linux-gnu, i386-elf32, cris-aout and z80-coff). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25828] New: nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=25828 Bug ID: 25828 Summary: nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Presumably since the creation of the pdp11-aout target 20 years ago, a symbol defined in a linker script that is referenced as a global variable in a source file will be shown as undefined by nm: T __start T _start T main t pr14962a.o 0002 t pr14962b.o T start U x Separately, symbols with the MSB set will be shown sign-extended to 64 bits, whereas PDP11 addresses are only 16 bits. A DATA_LENGTH 1000 A DATA_ORIGIN 8000 A TXT_LENGTH 0100 A TXT_ORIGIN 1004 D data_end 1000 T data_start 1000 D data_symbol 1000 D fred 0104 T text_end 0100 T text_start 0100 T text_symbol 0100 t tmpdir/script.o 8100 D tred -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] New: Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 Bug ID: 25829 Summary: Several ld tests fail for 16-bit targets like pdp11-aout Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Several tests in ld/testsuite/ld-scripts fail for the pdp11-aout target because address and/or size constants used in the tests are larger than will fit in a 16-bit address space. The choice of those constants is arbitrary, though, often just following the example test case that was submitted when the bug was filed. None of those tests are performing an operation where the numerical size of the constant is significant. Thus, these tests can be fixed for targets with 16-bit address spaces just by scaling down the constants. A related problem is the use of .long for references to test symbols. That requires a 32-bit relocation, which a 16-bit target can't do. Changing to .dc.a allows the relocation to fit the target address size. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25828] nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=25828 --- Comment #1 from Stephen Casner --- Created attachment 12462 --> https://sourceware.org/bugzilla/attachment.cgi?id=12462=edit Patch to fix undefined symbols and sign extension When bfd/pdp11.c was copied from bfd/aoutx.h, the #defines for external symbol types N_TEXT etc. were #undef'd and then #define'd with new values. But N_STAB was not changed even though the new value for N_EXT overlapped with it. This caused aout_link_write_symbols() to treat global symbols referenced in the source but defined in a linker script as undefined. Separately, in translate_symbol_table() the 16-bit symbol values were sign extended to unsigned long (e.g., 64 bits) when they really should be treated as unsigned so the value remains 16 bits. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] New: pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 Bug ID: 25830 Summary: pdp11-aout target does not support gdb, gdbserver, gprof Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Since the pdp11-aout target does not support gdb, gdbserver or gprof these should be excluded in configure. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 --- Comment #3 from Stephen Casner --- Oops, sorry. I do understand the autotools process, but it has been a few years and I was not paying enough attention so I overlooked it here. I will proceed as you have suggested. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #12 from Stephen Casner --- Nick, Had I known that my proposed change that fixes the test to pass for pdp11 would cause the test to fail for several others, I would not have submitted it. A much simpler and perhaps more fair change would have been to exclude pdp11 from the test. It's not really important that this test works for pdp11; I just wanted to fix all the unexpected failures for pdp11 and this test required a more significant fix than the others. What sort of infrastructure do you have for testing all targets? Perhaps I can replicate that? Sorry for imposing the extra work on you for the fixups you did. You should have simply replied that my change did not work for the new list of targets and I would have looked for a different solution. You could close this now or you could revert the commit and hand the problem back to me. I would then look for another solution, which might end up just being the exclusion of pdp11. Steve -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25828] nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=25828 --- Comment #3 from Stephen Casner --- (In reply to Nick Clifton from comment #2) > Patch approved - please apply. Was this an instruction to me to apply it myself? I have not established write access, but would be happy to do so if that is what you are suggesting. Steve -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #17 from Stephen Casner --- Nick, Thanks. I see that you still needed to bring in some of the changes to the test script that you made in your previous commit. I assumed all the changes you had to make to my first proposed fix were required because of my change to lay out the sections in a source file. But since changes were still required to exclude AIX and VMS targets and adjust the regexps for 64-bit Cygwin targets, that must mean those other targets were getting unexpected FAILs, too. I assumed pdp11 was an outlier, but I gather that testsuite compliance has not been strictly maintained. Please quantify how much disk space and time is required for the testing. I don't know if it would be feasible on my MacBook Pro. There are also a few complications imposed by the Mac using clang. I might be able to set up a server machine. Steve -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 --- Comment #4 from Stephen Casner --- Corrected patch request: https://sourceware.org/pipermail/binutils/2020-April/110709.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #13 from Stephen Casner --- Created attachment 12474 --> https://sourceware.org/bugzilla/attachment.cgi?id=12474=edit Revised patch Now I'm doubly sorry because I made this solution harder than necessary for myself as well as you. I misinterpreted the error message from nm to indicate that the section size adjustments in the linker script were not compatible with the a.out format, but your changes to pr18963.t included such an adjustment. All I really needed to do was to delete some zeros. I propose that you revert the commit you just did and apply the attached revised patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 --- Comment #2 from Stephen Casner --- Does this patch also cause some of the other targets' testsuites to fail? Scaling addresses down should not cause a problem, but if support for .dc.a is not universal that could be a problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #13 from Stephen Casner --- (In reply to Nick Clifton from comment #12) > You appear to be submitting the same patch as Jan... :-) > > The patch has the same problem as outlined here: > > https://sourceware.org/pipermail/binutils/2020-April/110597.html > > Basically the definitions of coff_swap_scnhdr_[in|out] need to > be changed so that other COFF based targets will build. Nick, perhaps some wires got crossed here? Perhaps you had two patches applied when you checked mine? My patch should not have any effect on any COFF based targets because the changes are almost entirely within the files specific to the pdp11-aout target. The only changes in common code are: - I needed to add i_magic to enum aout_magic in bfd/libaout.h. - In ld/lexsup.c, I needed to set config.text_read_only to TRUE in case 'n'. This is the same as the default value of that boolean as initialized in ldmain.c so I assume my change won't affect any non-pdp11 emulation. I need this change so that my change of the default value for pdp11 will work. That boolean is initialized to FALSE or TRUE in case 'N' and case OPTION_NO_OMAGIC. - In include/aout/aout64.h I needed to define IMAGIC and add two lines in N_DATADDR to return 0 when the magic number is IMAGIC. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #8 from Stephen Casner --- (In reply to Nick Clifton from comment #5) > The important issue is the extract symbols failure in the script.exp tests: > > Running ../../ld/testsuite/ld-scripts/script.exp ... > [...] > FAIL: extract symbols > > According to my logs this failure is new. Ie it only happens after applying > your patch. The aspect of my patch that exposed this failure is the change of the default output format to --omagic. The test would have failed for the code without my patch if the previous test had done "ld --omagic -o script script.o". The code that produces the erroneous data section size 4 rather than 0 is in bfd/pdp11.c function adjust_o_magic(). It was changed as part of the recent commit dda2980f54a by Alan Modra to fix PR 25569, but I'm not asserting that this commit was incorrect. I'm not sure what should change. For the failing test in question, objcopy is invoked with option --extract-symbol which should reduce the text and data sections to zero length. In the output bfd section structures the size is set to zero but the VMAs are not. Because objcopy also sets the user_set_vma flag to true, that causes the code in adjust_o_magic() to see that the difference between the vmas for data and bss is 4 while the size of data is 0, so it adds a padding of 4 to the data size. That's what comes out as 4 in the a.out header. Should objcopy also set the VMAs to zero? Or should it not set the user_set_vma flags? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #9 from Stephen Casner --- Another solution, perhaps the most straightforwad one, would be to change the code in adjust_o_magic() to not pad the size of the data section if the size of the bss section is zero. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #2 from Stephen Casner --- I could use some guidance regarding running the testsuite. After reading the binutils porting document I have installed dejagnu, but I don't know what information is needed in the global config, for example. Although I have a few simulated PDP11 environments set up with different operating systems, none of them have FTP and TELNET servers operating, as required for remote target testing. Was the test failure you observed found just in host-based validity checks on the output files? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #4 from Stephen Casner --- Created attachment 12414 --> https://sourceware.org/bugzilla/attachment.cgi?id=12414=edit ld make check summary log -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #3 from Stephen Casner --- Created attachment 12412 --> https://sourceware.org/bugzilla/attachment.cgi?id=12412=edit make check summary log I should add that I did run "make check" without any other preparation with the results as in the attached summary. More than one error was reported, which is different than the one error you cited. Also, I don't know if "Running target unix" and "Assuming target board is the local machine" are the desired conditions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25677] Changes to --*magic options for pdp11-aout target
https://sourceware.org/bugzilla/show_bug.cgi?id=25677 --- Comment #6 from Stephen Casner --- The key point I did not know is that failures were expected. I have been studying the detail log and the test scripts (I have programmed in Tcl, but it was about 30 years ago) to see why FAIL: extract scripts and the two FAIL: MEMORY failures preceding it occur. The symbol extraction is probably caused by my introduction of pdp11.sc so I can investigate that. The other two occur because the tests assume a word size and address space larger than 16 bits. For example, in ld-scripts/script.exp the "MEMORY with symbols" test sets DATA_LENGTH=0x1 but I think the choice of a number larger that 16 bits is arbitrary. Would it be reasonable to introduce changes to make the tests compatible with a 16-bit address space? For the test "MEMORY", the failure occurs because nm is not properly treating addresses as 16 bits, and that might be considered a real bug. Here's the output: 1004 D data_end 1000 T data_start 1000 D data_symbol 1000 D fred 0104 T text_end 0100 T text_start 0100 T text_symbol 0100 t tmpdir/script.o 8100 D tred For the PDP-11 with 16-bit address space this should more properly be: 1004 D data_end 1000 T data_start 1000 D data_symbol 1000 D fred 0104 T text_end 0100 T text_start 0100 T text_symbol 0100 t tmpdir/script.o 8100 D tred There is pretty clearly a bug where 0x8100 gets sign extended to 64 bits. One side question you might be able to answer for me: where is "fail" implemented? I searched but could not find it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 --- Comment #5 from Stephen Casner --- Created attachment 12486 --> https://sourceware.org/bugzilla/attachment.cgi?id=12486=edit Additional patch for mingw and cygwin The idiom of the tail wagging the dog comes to mind here. I was just trying to do a good deed to clear up the long-standing test failures for the pdp11 target. Obviously my experience is not broad enough to realize the range of different behaviors exhibited by the many targets supported by binutils. (In reply to Nick Clifton from comment #4) > I made one small change - using a 16K region size for the > text region in the memory tests as this pacified the PE > targets. Using 16K is fine. I had dropped it down to 2K to avoid the need to also change 0+ to 0* in the regexps if nm is changed to print 4-digit hex addresses for 16-bit targets as I'd like to do, but that regexp change would be fine. > (They were setting the 'tred' symbol to a value > of 0x10900 - even on 32-bit targets!. I think that > this is a bug related to the image base setting, but I did > not have time to investigate). So you're saying that if the address was below some threshold then the default offset of 0x1 would be added, but 16K was high enough to avoid that? (The ld doc description of --image-base says the default for dlls is 0x1000 (one fewer 0s), but I don't know if this link in these tests would be considered a dll. Also, that text says --image-base is exclusive to the i386 PE targeted port, but it sounds like that comment is out of date.) > I also found that 64-bit PE targets would fail the default-script > tests because they need the "--image-base 0" option added to > the linker command line in order to work. Since there is > no way to conditionally add command line options in the > run_dump_tests I just marked them as xfail. I see that the default-script tests as they were before my changes here would pass cleanly on x86_64-mingw64 but they would already fail for x86_64-cygwin because 0x1 is added. In fact, x86_64-cygwin has 23 unexpected FAILs. Are there many targets that don't pass the ld testsuite cleanly? The target-specific --image-base option can be added conditionally to LDFLAGS in default-script.exp as it already does to add --local-store for spu*-*-* so the tests would not have to be skipped for *-*-mingw64 x86_64-*-cygwin. I've done that in this additional patch. I tested x86_64-mingw64 and x86_64-cygwin. I hope it would not cause a failure for anything else matching *-*-mingw64 x86_64-*-cygwin. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26001] PDP11 gas confuses register names and symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26001 --- Comment #1 from Stephen Casner --- Created attachment 12550 --> https://sourceware.org/bugzilla/attachment.cgi?id=12550=edit Patch for the bug This patch fixes the bug, but I need to add a test case and change logs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26001] PDP11 gas confuses register names and symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26001 Stephen Casner changed: What|Removed |Added Target||pdp11-aout -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26001] New: PDP11 gas confuses register names and symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26001 Bug ID: 26001 Summary: PDP11 gas confuses register names and symbols Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Attempting to assemble the instruction jsr pc,sprintf results in error message "Too many operands". This occurs because "sp" is interpreted as a register name and so "rintf" is considered excess. Not to mention that "jsr pc,sp" is not a valid instruction anyway. But the failure would also occur with "mov r0,space" where "mov r0,sp" would be valid. It's hard to believe that this bug was present since the PDP11 code was added in 2001, but perhaps the C compiler always prefixes symbols with . or _ so this bug would not have been exposed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26001] PDP11 gas confuses register names and symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26001 Stephen Casner changed: What|Removed |Added Assignee|unassigned at sourceware dot org |casner at acm dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26001] PDP11 gas confuses register names and symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26001 Stephen Casner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Stephen Casner --- Fix and test implemented. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #2 from Stephen Casner --- git bisect finds this is the commit where the problem began: commit 1038406a8f6609ad0a449746da70393b0835f699 Author: Nick Alcock Date: Tue Jan 5 13:25:56 2021 + libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD This complex morass inherited from libopcodes, which endeavours to implement the effect of specifying ../bfd/libbfd.la in _LIBADD without actually doing so, appears to be working around a libtool bug which as far as I can see is no longer present (i.e., the install directory no longer appears in -L arguments in libtool link-mode invocations, so there is no danger of picking up old libbfds or other dependent libraries). Replaced with a simple reference to libbfd.la in the appropriate place. Also adjusted things a little more so that libctf.la and libctf-nobfd.la are self-contained, even when linking statically. This opens up the possibility of running libtool to link against libctf from inside the (upcoming) testsuite. libctf/ChangeLog 2021-01-05 Nick Alcock * configure.ac (BFD_LIBADD): Remove. (BFD_DEPENDENCIES): Likewise. Remove associated cases. (SHARED_LIBADD): Rename to... (CTF_LIBADD): ... this. Stick in a suitable libiberty even when linking statically. * Makefile.am (libctf_nobfd_la_LIBADD): Adjust accordingly. libctf uses libintl. (libctf_la_LIBADD): Reference libbfd.la directly, not via BFD_LIBADD. (libctf_la_DEPENDENCIES): Remove. * Makefile.in: Regenerate. * configure: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Stephen Casner changed: What|Removed |Added Attachment #13183|tarball of possibly |tarball of possibly description|relevant configs, |relevant configs, Makefiles |MakefilesAdded tarball of | |these files. Let me know | |if any others would be | |helpful. auge12> tar czf | |relevant.tgz intl/Makefile | |intl/config.* | |libctf/Makefile libc| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] New: libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Bug ID: 27297 Summary: libctf.a malformed, build fails on x86_64-apple-darwin18.7.0 Product: binutils Version: 2.36 Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Created attachment 13182 --> https://sourceware.org/bugzilla/attachment.cgi?id=13182=edit 2.36 build log I first encountered this problem when trying to build a pdp11-aout cross on x86_64-apple-darwin18.7.0, but the problem is there for the native build as well. I have not tested to see if other hosts are affected (this is all I have). This build is using the macOS system tools (clang, etc.). This problem does NOT occur with 2.35.2. It DOES occur with 2.36 and HEAD. The problem arises here: /bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -I/Users/casner/src/gnu/binutils-gdb/libctf/../zlib -g -O2 -version-info 0:0:0 -export-symbols-regex ctf_.* -Wl,-no_pie -o libctf.la -rpath /usr/local/lib libctf_la-ctf-archive.lo libctf_la-ctf-dump.lo libctf_la-ctf-create.lo libctf_la-ctf-decl.lo libctf_la-ctf-error.lo libctf_la-ctf-hash.lo libctf_la-ctf-labels.lo libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo libctf_la-ctf-lookup.lo libctf_la-ctf-open.lo libctf_la-ctf-sha1.lo libctf_la-ctf-string.lo libctf_la-ctf-subr.lo libctf_la-ctf-types.lo libctf_la-ctf-util.lo libctf_la-ctf-open-bfd.lo ../bfd/libbfd.la -L/Users/casner/src/gnu/binutils-gdb/native/libctf/../libiberty -liberty ./../intl/libintl.a -liconv -L./../zlib -lz *** Warning: Linking the shared library libctf.la against the *** static library ./../intl/libintl.a is not portable! libtool: link: ar rc .libs/libctf.a ./../intl/libintl.a libctf_la-ctf-archive.o libctf_la-ctf-dump.o libctf_la-ctf-create.o libctf_la-ctf-decl.o libctf_la-ctf-error.o libctf_la-ctf-hash.o libctf_la-ctf-labels.o libctf_la-ctf-dedup.o libctf_la-ctf-link.o libctf_la-ctf-lookup.o libctf_la-ctf-open.o libctf_la-ctf-sha1.o libctf_la-ctf-string.o libctf_la-ctf-subr.o libctf_la-ctf-types.o libctf_la-ctf-util.o libctf_la-ctf-open-bfd.o This causes libctf.a to contain libintl.a as its first component file: auge48> ar -t libctf/.libs/libctf.a __.SYMDEF SORTED libintl.a libctf_la-ctf-archive.o libctf_la-ctf-dump.o libctf_la-ctf-create.o libctf_la-ctf-decl.o libctf_la-ctf-error.o libctf_la-ctf-hash.o libctf_la-ctf-labels.o libctf_la-ctf-dedup.o libctf_la-ctf-link.o libctf_la-ctf-lookup.o libctf_la-ctf-open.o libctf_la-ctf-sha1.o libctf_la-ctf-string.o libctf_la-ctf-subr.o libctf_la-ctf-types.o libctf_la-ctf-util.o libctf_la-ctf-open-bfd.o That causes the link of objdump to fail, ending the build: libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I/Users/casner/src/gnu/binutils-gdb/binutils/../zlib -g -O2 -Wl,-no_pie -o objdump objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o rdcoff.o bucomm.o version.o filemode.o elfcomm.o od-macho.o ../opcodes/.libs/libopcodes.a ../libctf/.libs/libctf.a -L/Users/casner/src/gnu/binutils-gdb/native/zlib -L/Users/casner/src/gnu/binutils-gdb/native/libctf/../libiberty /Users/casner/src/gnu/binutils-gdb/native/bfd/.libs/libbfd.a -liberty ../bfd/.libs/libbfd.a -ldl -lz ../libiberty/libiberty.a ./../intl/libintl.a -liconv ld: warning: ignoring file ../libctf/.libs/libctf.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 Undefined symbols for architecture x86_64: "_ctf_archive_iter", referenced from: _dump_bfd in objdump.o "_ctf_bfdopen_ctfsect", referenced from: _dump_bfd in objdump.o "_ctf_close", referenced from: _dump_bfd in objdump.o "_ctf_dict_close", referenced from: _dump_bfd in objdump.o "_ctf_dict_open", referenced from: _dump_bfd in objdump.o "_ctf_dump", referenced from: _dump_ctf_archive_member in objdump.o "_ctf_errmsg", referenced from: _dump_bfd in objdump.o _dump_ctf_errs in objdump.o _dump_ctf_archive_member in objdump.o "_ctf_errno", referenced from: _dump_ctf_archive_member in objdump.o "_ctf_errwarning_next", referenced from: _dump_ctf_errs in objdump.o "_ctf_import", referenced from: _dump_ctf_archive_member in objdump.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Stephen Casner changed: What|Removed |Added Host||x86_64-apple-darwin18.7.0 Target||pdp11-aout, ||x86_64-apple-darwin18.7.0, ||others? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #1 from Stephen Casner --- Created attachment 13183 --> https://sourceware.org/bugzilla/attachment.cgi?id=13183=edit tarball of possibly relevant configs, MakefilesAdded tarball of these files. Let me know if any others would be helpful. auge12> tar czf relevant.tgz intl/Makefile intl/config.* libctf/Makefile libc Added tarball of these files. Let me know if any others would be helpful. auge12> tar czf relevant.tgz intl/Makefile intl/config.* libctf/Makefile libctf/config.* libctf/libctf*.la libctf/.libs/libctf.a auge13> v relevant.tgz -rw-r--r--+ 1 casner staff 999896 Jan 30 23:19 relevant.tgz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #4 from Stephen Casner --- Bug 27360 appears to be related, but I'm not sure if they can be called duplicates. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Stephen Casner changed: What|Removed |Added CC||casner at acm dot org --- Comment #4 from Stephen Casner --- The same commit was fingered in bug 27297; a fix is in progress there. -- You are receiving this mail because: You are on the CC list for the bug.
