Bug 229049

Summary: Mk/bsd.port.mk relies on to-be-removed objdump
Product: Ports & Packages Reporter: Ed Maste <emaste>
Component: Ports FrameworkAssignee: Port Management Team <portmgr>
Status: Closed FIXED    
Severity: Affects Only Me CC: ports-bugs
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://reviews.freebsd.org/D15904
Bug Depends on:    
Bug Blocks: 229046    

Description Ed Maste freebsd_committer 2018-06-15 17:13:46 UTC
objdump is being removed from the base system (target 12.0). It is currently being used by Mk/bsd.port.mk. Using readelf instead should be relatively straightforward.

objdump -R emits (only) dynamic relocs, while readelf -r emits all relocs; a little awk or sed triggering on the headers (e.g. "Relocation section with addend (.rela.dyn):") may work.
Comment 1 Mathieu Arnold freebsd_committer 2018-06-19 14:04:03 UTC
I was kinda hoping I would never have to touch that make target and that awk script.

Now the problem is going to be find a port that actually triggers those.

It seems readelf only output the file names if more than one file is passed as an argument while objdump always outputs it.  Is there some flag I could not find that would make readelf always write its `File:` header?
Comment 2 Mathieu Arnold freebsd_committer 2018-06-19 14:45:20 UTC
There are three ports using ${OBJDUMP}:

devel/abi-compliance-checker
devel/aros-sdk
net/ipxe

Not sure how they can be fixed.
Comment 3 Ed Maste freebsd_committer 2018-06-19 14:49:35 UTC
(In reply to Mathieu Arnold from comment #2)
Ports that need objdump can just require the binutils port be installed.
Comment 4 Mathieu Arnold freebsd_committer 2018-06-19 14:57:01 UTC
Started a review to fix the problem.
Comment 5 Ed Maste freebsd_committer 2018-06-19 14:57:48 UTC
Ah, it looks like the objdump use is just to see if there is a reference to gets, mktemp, tempnam, tmpnam, or in audit mode also strcpy, strcat, sprintf.

Equivalent information (in a different format) should be available from `nm --dynamic`, and nm also accepts `--print-file-name` if desired.
Comment 6 Mathieu Arnold freebsd_committer 2018-06-20 08:01:57 UTC
Mmmm, nm --print-file-name looks interesting. But the format it uses is harder to parse, especially if the file path contains a space.
I think I'll keep using readelf with a nonexistent first argument, which does what we need here.
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2018-06-25 06:49:50 UTC
New errorlog on aarch64-current with 'configure: error: unable to find objdump':

http://thunderx1.nyi.freebsd.org/data/head-arm64-default/p471899_s334756/logs/errors/mbuffer-20180505.log
Comment 8 Ed Maste freebsd_committer 2018-06-29 19:41:08 UTC
(In reply to Mark Linimon from comment #7)
That failure is on arm64 which has never installed GNU objdump. It should be added to PR 229046 or as a blocker of PR 229046, or just add USE_BINUTILS=yes to the port.
Comment 9 Tobias Kortkamp freebsd_committer 2018-06-30 03:53:22 UTC
(In reply to Ed Maste from comment #8)
mbuffer was already fixed in ports r472625
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2018-06-30 04:24:27 UTC
(In reply to Tobias Kortkamp from comment #9)

I hadn't notice that commit.  Thanks.
Comment 11 commit-hook freebsd_committer 2018-06-30 08:37:59 UTC
A commit references this bug:

Author: mat
Date: Sat Jun 30 08:37:33 UTC 2018
New revision: 473605
URL: https://svnweb.freebsd.org/changeset/ports/473605

Log:
  Convert to readelf.

  objdump is being removed from HEAD, make sure everything still works
  when this happens.

  PR:		229049
  Reported by:	emaste
  Sponsored by:	Absolight
  Differential Revision:	https://reviews.freebsd.org/D15904

Changes:
  head/Mk/Scripts/security-check.awk
  head/Mk/bsd.port.mk
Comment 12 Ed Maste freebsd_committer 2018-11-30 14:05:58 UTC
There are currently two instances of objdump in Mk/:

Mk/bsd.commands.mk
70:OBJDUMP?=            /usr/bin/objdump

Mk/bsd.port.mk
1862:BINUTILS?= ADDR2LINE AR AS CPPFILT GPROF LD NM OBJCOPY OBJDUMP RANLIB \

The second (bsd.port.mk) is fine: it is setting up a loop for tools to be set under USE_BINUTILS. I'm not sure what we should do about the first, probably just remove it.

That said, I think this PR can be closed?