Re: Fwd: [openbsd/src] https://redmine.pfsense.org/issues/14444 (PR #39)
Hi Jonathan,
Thank you for contributing! There are a few more steps you'll need to take.
Please refer to the last ("Preparing a Diff") section of the FAQ for
this: https://www.openbsd.org/faq/faq5.html#Diff
It explains how to use your local Git repo to make a diff. For emailing,
you'll want to send a plain-text email containing the diff (in body, not
attachment) to this list -- tech@openbsd.org. You will also want to put
"pf: " at the beginning of the subject line, so we know what your diff
relates to.
--Aaron
On 6/18/23 08:06, Jonathan Lee wrote:
Hello I was directed to email this mailing list.
Docker container OS fingerprints are missing from p0f database.
Please see following Redmine that helps showcase this. The closed pull
request also lists location in database file for os fingerprints.
Jonathan Lee
Adult Student
-- Forwarded message -
From: Stuart Henderson
Date: Sun, Jun 18, 2023, 6:53 AM
Subject: Re: [openbsd/src] https://redmine.pfsense.org/issues/1 (PR #39)
To: openbsd/src
Cc: Jonathan David Lee , Author <
aut...@noreply.github.com>
Closed #39 .
—
Reply to this email directly, view it on GitHub
, or unsubscribe
.
You are receiving this because you authored the thread.Message ID:
Re: net80211: new Tx rate adaptation module (iwn + iwm)
On Thu, 2021-03-11 at 10:58 +0100, Stefan Sperling wrote: > Generally, iwm tends to prefer 5 GHz for me in most locations, > but > there are heuristics involved in selecting the band. You could > try > tweaking these values in ieee80211_var.h to see if it you can > manage > to tip iwm over into the 5 GHz band: > > #define IEEE80211_RSSI_THRES_2GHZ (-60) /* in > dBm */ > #define IEEE80211_RSSI_THRES_5GHZ (-70) /* in > dBm */ > #define IEEE80211_RSSI_THRES_RATIO_2GHZ 60 /* in > percent */ > #define IEEE80211_RSSI_THRES_RATIO_5GHZ 50 /* in > percent */ > > The current values are based on highly scientific and ruthlessly > thorough trials which I conducted at my flat ;-) OK that's worth a try. What do these settings mean? Also, I just realized I could set the channel manually with the 'chan' option to ifconfig(8). I set it to the 5 GHz channel of my network and I didn't notice an improvement. Maybe it didn't really switch channels? Thanks for your help! --Aaron
Re: net80211: new Tx rate adaptation module (iwn + iwm)
On Tue, 2021-03-09 at 14:48 +0100, Stefan Sperling wrote: > This implements a new rate adaptation module for net80211, called > "RA", > which resulted from a long discussion and exchanges of various > diffs > between Christian Ehrhardt and myself, targeting problems with > MiRA. > > Tests with any of the various iwn(4) and iwm(4) devices are very > welcome. I've only been using it for a few hours, but it is clearly better than what was in my -CURRENT snapshot from this morning. Measuring using speedof.me, I got about a 25% increase in download speed and about a 35% increase in upload speed. There's some uncertainty because I'm using a crowded 2.4 GHz spectrum and sometimes it's more congested than at other times. Subjectively, it feels a lot better when browsing the web, FWIW. For some reason, iwm has never used the much less congested 5GHz band that Linux uses on the same machine, resulting in only a small fraction of the speed I get when I am booted into Linux (this is not a change caused by your patch). Your patch makes the connection usable for me. Nice work! :) --Aaron === $ ifconfig iwm0 iwm0: flags=8843 mtu 1500 lladdr xx:xx:xx:xx:xx:xx index 2 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (HT-MCS13 mode 11n) status: active ieee80211: nwid x chan 6 bssid xx:xx:xx:xx:xx:xx 53% wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.xx.xxx netmask 0xff00 broadcast 192.168.xx.255 OpenBSD 6.9-beta (GENERIC.MP) #0: Wed Mar 10 17:27:36 PST 2021 aa...@millipede.iforgotmy.name:/var/git/src/sys/arch/amd64/compile /GENERIC.MP real mem = 16827916288 (16048MB) avail mem = 16302530560 (15547MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET37W (1.15 )" date 09/06/2016 bios0: LENOVO 20BSCTO1WW acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.65 MHz, 06- 3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D TES64,MWAIT,DS- CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE 4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI 1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTR L,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06- 3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D TES64,MWAIT,DS- CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE 4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI 1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTR L,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06- 3d-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D TES64,MWAIT,DS- CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE 4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI 1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTR L,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06- 3d-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D TES64,MWAIT,DS- CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE
sndio support for Rust (cpal crate) - review requested
Hello all, I have added support for a host for the sndio(7) system to the cpal Rust audio library[1]. I am seeking reviewers who are familiar with the sndio API and with Rust. My PR is here: https://github.com/RustAudio/cpal/pull/493 Although it's not the most straightforward code it's only about 1k SLOC so I don't expect it'll take a long time to review. The cpal crate is a big deal in the Rust audio ecosystem -- it'll enable OpenBSD audio support for the two major game engines (ggez and amethyst), and some various audio tools as well.[2] If anyone would be willing to test it on their machine and report back, that would be appreciated as well: 1. Install the rust package (if not already installed) 2. git clone https://github.com/conwayste/cpal \ -b aaron/openbsd_sndio_host 3. cd cpal 4. cargo run --example beep (there are some other examples under examples/) Thanks in advance :) Aaron Miller [1] https://crates.io/crates/cpal [2] https://rust.audio/
Re: Python 3.8 os.listdir EINVAL on large directories
On Sun, 2020-07-26 at 17:05 +0100, Stuart Henderson wrote:
> Moving to tech.
>
> In gmane.os.openbsd.misc, you wrote:
> > Hi all,
> >
> > I am getting a stacktrace from the borg command in the borgbackup
> > package while checking a backup (see bottom of email for full
> > output, since it's verbose). The relevant part is this:
> >
> > filenames = os.listdir(os.path.join(data_path, dir))
> > OSError: [Errno 22] Invalid argument:
> > '/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12'
> >
> > This is same error is reproducible with a test Python 3.8 program:
> >
> > #!/usr/bin/env python
> >
> > import os
> > os.listdir('/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/')
> >
> > Running ktrace & kdump reveals the error is from calling
> > getdents(2):
> >
> > 76903 python3.8
> > CALL open(0x1ec7f06de3b0,0x3)
> > 76903 python3.8
> > NAMI "/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/"
> > 76903 python3.8 RET open 3
> > [...]
> > 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> > 76903 python3.8 RET getdents 16384/0x4000
> > [...]
> > 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> > 76903 python3.8 RET getdents 16384/0x4000
> > [...]
> > 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> > 76903 python3.8 RET getdents 16384/0x4000
> > [...]
> > 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> > 76903 python3.8 RET getdents -1 errno 22 Invalid argument
> >
> > Looking at the man page for getdents(2), I found it interesting
> > that it says this call "is not a portable interface and should not
> > be used directly by applications" and it recommends using
> > readdir(3) instead.
>
> ktrace only shows system calls not library functions. I don't
> see python calling getdents directly, there is a fair chance that
> python is calling readdir, and readdir is calling getdents.
>
> > To give you a rough idea of the number of files and filename sizes
> > in this directory:
> >
> > $ ls /mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/ | wc
> > 15341534 10738
>
> I haven't been able to recreate this including over nfs yet.
> What filesystem type and mount options?
It's a freshly created 1.3 TB ext3 filesystem created with
mkfs.ext3 on Linux. No mount options, just:
# mount /dev/sd2k /mnt
Even though I can read it just fine on Linux and OpenBSD (other
than with os.listdir in Python), fsck_ext2fs(8) shows errors:
# fsck_ext2fs -d /dev/sd2k
** /dev/rsd2k
superblock mismatches
offset 94, original 387159720, alternate 0
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN
FIRST ALTERNATE
/dev/rsd2k: BLOCK SIZE DETERMINED TO BE ZERO
If you think it would help, I can make a .tar.gz of a directory
with zero-sized files having the same exact file names.
>
> getdents(2) :-
>
>format. Up to nbytes of data will be transferred. nbytes must be greater
>than or equal to the block size associated with the file (see stat(2)).
>Some filesystems may not support getdents() with buffers smaller than this
>size.
> ...
>getdents() will fail if:
> ...
>[EINVAL] The file referenced by fd is not a directory, or nbytes
> is too small for returning a directory entry or block of
> entries, or the current position pointer is invalid.
>
> > Where does the problem lie -- the upstream Python code, the
> > OpenBSD-specific patches in its port definition, or somewhere
> > else? And in case it matters, this is a -current amd64 system,
> > with "sysupgrade -s" executed on 7/15.
> >
> > Thank you,
> > Aaron Miller
> >
> > --
> > Exception ignored in: > 0x1e17e13fd310>
> > Traceback (most recent call last):
> > File "/usr/local/lib/python3.8/site-
> > packages/borg/repository.py", line 180, in __del__
> > assert False, "cleanup happened in Repository.__del__"
> > AssertionError: cleanup happened in Repository.__del__
> > Local Exception
> > Traceback (most recent call last):
> > File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> > line 4565, in main
> > exit_code = archiver.run(args)
> > File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> > line 4497, in run
> > return set_ec(func(args))
> > File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> > line 161, in wrapper
> > with repository:
Re: ld patch that greatly speeds up linking large programs with debug symbols
On February 23, 2019 2:50:46 AM PST, Jeremie Courreges-Anglas wrote: >On Sat, May 07 2016, Stefan Kempf wrote: >> Aaron Miller wrote: >>> Hi All, >>> >>> I was experiencing ~8 minute linking times for a large C++ >application >>> I have been working on when running -current on amd64. It turns out >>> that the decade-old version of ld in the OpenBSD source tree has a >bug >>> that causes quadratic complexity for some linking operations when >>> debug symbols are present. I found a patch from 2006 in a mailing >list >>> archive that fixes this; I adapted it to work with OpenBSD by >editing >>> files that are normally regenerated (I couldn't figure out how to do >>> automatically regenerate them). >>> >>> Here is the original patch: >>> https://sourceware.org/ml/binutils/2006-08/msg00334.html >>> >>> I have rebuilt the kernel and system with this ld and everything >runs >>> identically to the system linked with the unpatched ld. >>> >>> Please test this and let me know if this could get into the tree, >and >>> if not, what changes I need to make. Thanks! >> >> Interesting! >> >> About the autogenerated files: it looks you already made the >additions >> to bfd/linker.c, bfd/targets.c and bfd/libbfd.h that should end up >> in bfd-in2.h and libbfd-in.h. >> >> To regenerate them, make sure you first did a "make obj" in the root >of >> your source tree. Then run "make depend" from gnu/usr.bin. >Afterwards, >> to to gnu/usr.bin/binutils-2.17/obj/bfd and run "make headers". >> headers". That did the trick for me. > >A bit late to the party, > >I think this diff breaks ld.bfd(1) operations in some special cases. > >http://build-failures.rhaalovely.net//sparc64/2019-02-03/textproc/mupdf.log > >shows a double free on sparc64. A similar crash can be reproduced on >amd64 using MALLOC_OPTIONS: > >--8<-- >russell /usr/ports/pobj/mupdf-1.14.0/mupdf-1.14.0-source$ >MALLOC_OPTIONS=S egdb --args ld.bfd -r -b binary -o >build/release/resources/fonts/urw/NimbusMonoPS-Bold.cff.o >resources/fonts/urw/NimbusMonoPS-Bold.cff >GNU gdb (GDB) 7.12.1 >Copyright (C) 2017 Free Software Foundation, Inc. >License GPLv3+: GNU GPL version 3 or later ><http://gnu.org/licenses/gpl.html> >This is free software: you are free to change and redistribute it. >There is NO WARRANTY, to the extent permitted by law. Type "show >copying" >and "show warranty" for details. >This GDB was configured as "x86_64-unknown-openbsd6.4". >Type "show configuration" for configuration details. >For bug reporting instructions, please see: ><http://www.gnu.org/software/gdb/bugs/>. >Find the GDB manual and other documentation resources online at: ><http://www.gnu.org/software/gdb/documentation/>. >For help, type "help". >Type "apropos word" to search for commands related to "word"... >Reading symbols from ld.bfd...done. >(gdb) r >Starting program: /usr/bin/ld.bfd -r -b binary -o >build/release/resources/fonts/urw/NimbusMonoPS-Bold.cff.o >resources/fonts/urw/NimbusMonoPS-Bold.cff >ld.bfd(20556) in free(): bogus pointer (double free?) >0xdbdbdbdbdbdbdbdb > >Program received signal SIGABRT, Aborted. >thrkill () at -:3 >3 -: No such file or directory. >(gdb) bt >#0 thrkill () at -:3 >#1 0x07d40bd157fe in _libc_abort () at >/usr/src/lib/libc/stdlib/abort.c:51 >#2 0x07d40bca4909 in wrterror (d=0x7d3ab4b9be0, msg=0x7d40bc82ed6 >"bogus pointer (double free?) %p") at >/usr/src/lib/libc/stdlib/malloc.c:297 >#3 0x07d40bca7970 in findpool (p=0xdbdbdbdbdbdbdbdb, >argpool=, foundpool=0x7f7cb180, >saved_function=0x7f7cb178) at >/usr/src/lib/libc/stdlib/malloc.c:1323 >#4 0x07d40bca4af0 in ofree (argpool=0x7f7cb1d8, >p=0xdbdbdbdbdbdbdbdb, clear=0, check=0, argsz=0) at >/usr/src/lib/libc/stdlib/malloc.c:1337 >#5 0x07d40bca4a10 in free (ptr=0xdbdbdbdbdbdbdbdb) at >/usr/src/lib/libc/stdlib/malloc.c:1451 >#6 0x07d16b97be4a in bfd_elf_final_link (abfd=0x7d4006f0a00, >info=0x7d16b9dc1f8 ) at >/usr/src/gnu/usr.bin/binutils-2.17/bfd/elflink.c:8623 >#7 0x07d16b8fe7f2 in ldwrite () at >/usr/src/gnu/usr.bin/binutils-2.17/ld/ldwrite.c:557 >#8 0x07d16b8fbde7 in main (argc=7, argv=0x7f7cb778) at >/usr/src/gnu/usr.bin/binutils-2.17/ld/ldmain.c:496 >(gdb) frame 6 >#6 0x07d16b97be4a in bfd_elf_final_link (abfd=0x7d4006f0a00, >info=0x7d16b9dc1f8 ) at >/usr/src/gnu/usr.bin/binutils-2.17/bfd/elflink.c:8623 >8623
ld patch that greatly speeds up linking large programs with debug symbols
Hi All,
I was experiencing ~8 minute linking times for a large C++ application
I have been working on when running -current on amd64. It turns out
that the decade-old version of ld in the OpenBSD source tree has a bug
that causes quadratic complexity for some linking operations when
debug symbols are present. I found a patch from 2006 in a mailing list
archive that fixes this; I adapted it to work with OpenBSD by editing
files that are normally regenerated (I couldn't figure out how to do
automatically regenerate them).
Here is the original patch:
https://sourceware.org/ml/binutils/2006-08/msg00334.html
I have rebuilt the kernel and system with this ld and everything runs
identically to the system linked with the unpatched ld.
Please test this and let me know if this could get into the tree, and
if not, what changes I need to make. Thanks!
Index: bfd/bfd-in2.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/bfd-in2.h,v
retrieving revision 1.4
diff -u -p -r1.4 bfd-in2.h
--- bfd/bfd-in2.h25 May 2015 14:56:26 -1.4
+++ bfd/bfd-in2.h17 Apr 2016 05:14:15 -
@@ -5068,7 +5068,7 @@ typedef struct bfd_target
/* Check if SEC has been already linked during a reloceatable or
final link. */
- void (*_section_already_linked) (bfd *, struct bfd_section *);
+ void (*_section_already_linked) (bfd *, struct bfd_section *,
struct bfd_link_info *);
/* Routines to handle dynamic symbols and relocs. */
#define BFD_JUMP_TABLE_DYNAMIC(NAME) \
@@ -5128,10 +5128,10 @@ bfd_boolean bfd_link_split_section (bfd
#define bfd_link_split_section(abfd, sec) \
BFD_SEND (abfd, _bfd_link_split_section, (abfd, sec))
-void bfd_section_already_linked (bfd *abfd, asection *sec);
+void bfd_section_already_linked (bfd *abfd, asection *sec, struct
bfd_link_info *);
-#define bfd_section_already_linked(abfd, sec) \
- BFD_SEND (abfd, _section_already_linked, (abfd, sec))
+#define bfd_section_already_linked(abfd, sec, info) \
+ BFD_SEND (abfd, _section_already_linked, (abfd, sec, info))
/* Extracted from simple.c. */
bfd_byte *bfd_simple_get_relocated_section_contents
Index: bfd/elf-bfd.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elf-bfd.h,v
retrieving revision 1.4
diff -u -p -r1.4 elf-bfd.h
--- bfd/elf-bfd.h25 Aug 2015 02:24:49 -1.4
+++ bfd/elf-bfd.h17 Apr 2016 05:14:16 -
@@ -1371,6 +1371,9 @@ struct elf_obj_tdata
/* Used to determine if we are creating an executable. */
bfd_boolean executable;
+
+ /* Symbol buffer. */
+ Elf_Internal_Sym *symbuf;
};
#define elf_tdata(bfd)((bfd) -> tdata.elf_obj_data)
@@ -1503,11 +1506,11 @@ extern bfd_boolean _bfd_elf_match_sectio
extern bfd_boolean bfd_elf_is_group_section
(bfd *, const struct bfd_section *);
extern void _bfd_elf_section_already_linked
- (bfd *, struct bfd_section *);
+ (bfd *, struct bfd_section *, struct bfd_link_info *);
extern void bfd_elf_set_group_contents
(bfd *, asection *, void *);
extern asection *_bfd_elf_check_kept_section
- (asection *);
+ (asection *, struct bfd_link_info *);
extern void _bfd_elf_link_just_syms
(asection *, struct bfd_link_info *);
extern bfd_boolean _bfd_elf_copy_private_header_data
@@ -1703,7 +1706,7 @@ extern bfd_boolean _bfd_elf_symbol_refs_
(struct elf_link_hash_entry *, struct bfd_link_info *, bfd_boolean);
extern bfd_boolean bfd_elf_match_symbols_in_sections
- (asection *sec1, asection *sec2);
+ (asection *, asection *, struct bfd_link_info *);
extern bfd_boolean _bfd_elf_setup_sections
(bfd *);
Index: bfd/elf.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elf.c,v
retrieving revision 1.7
diff -u -p -r1.7 elf.c
--- bfd/elf.c13 Jan 2015 20:05:43 -1.7
+++ bfd/elf.c17 Apr 2016 05:14:18 -
@@ -3101,7 +3101,7 @@ assign_section_numbers (bfd *abfd, struc
s, s->owner);
/* Point to the kept section if it has the same
size as the discarded one. */
- kept = _bfd_elf_check_kept_section (s);
+ kept = _bfd_elf_check_kept_section (s, link_info);
if (kept == NULL)
{
bfd_set_error (bfd_error_bad_value);
@@ -8674,7 +8674,8 @@ elf_sym_name_compare (const void *arg1,
symbols. */
bfd_boolean
-bfd_elf_match_symbols_in_sections (asection *sec1, asection *sec2)
+bfd_elf_match_symbols_in_sections (asection *sec1, asection *sec2,
+ struct bfd_link_info *info)
{
bfd *bfd1, *bfd2;
const struct elf_backend_data *bed1, *bed2;
@@ -8732,21 +8733,37 @@ bfd_elf_match_symbols_in_sections (asect
if (symcount1 == 0 || symcount2 == 0)
return FALSE;
- isymbuf1 = bfd_elf_get_elf_syms (bfd1, hdr1, symcount1, 0,
- NULL, NULL, NULL);
- isymbuf2 = bfd_elf_get_elf_syms (bfd2,
