0

I am writing a number AWS Lambda functions using Go. Common functionality is divided into modules, for example I have a module (M1) that provides an implementation of an interface with a backing store in terms of DynamoDB (so has a dependency on AWS Go SDK).

In one Lambda function (F1) I import M1, so the dependency graph for a code path looks like this:

F1 -> M1 -> SDK -> dynamodb.DynamoDB.PutItem

Being AWS I need to write a corresponding IAM policy to permit F1 to execute PutItem.

At the moment I identify the AWS SDK calls by hand and fix any errors that are loggged in CloudWatch.

My goal is to determine whether there is a way to get the Go toolchain to identify which functions are invoked from a given module/import.

So far I can tried a few variations of the below:

# this doesn't return much as most of my code lives within directories
# under main
go mod why "github.com/aws/aws-sdk-go"
# github.com/aws/aws-sdk-go
(main module does not need package github.com/aws/aws-sdk-go)

# this only identifies a single F1 {-> ...} -> SDK invocation
# but not all of them
grep -r github.com/aws/aws-sdk-go --include="*.go" \
  | cut -f2 -d'"' \
  | sort -u \
  | xargs go mod why

I've not dipped into the source of go build and go mod why, but so far I can't see a way to convince "go mod why" to understand simple glob expansions/regex and the corresponding invocation points. I also haven't made any headway on the second order deps (i.e. M1->SDK).

Anonimoak
  • 1
  • 1

1 Answers1

1

go mod graph will give you your dependency graph, but that won't tell you what functions are being called; that's not in the scope of dependency management, which operates at the module level. To see what functions are being called you'd need to either parse the source via AST, or instrument the binary with e.g. pprof.

Adrian
  • 42,911
  • 6
  • 107
  • 99
  • Thanks, `go mod graph` served as a great starting point. Annoyingly the packages that it uses are all internal and inaccessible programmatically. Led me to `golang.org/x/tools/go/packages` and seeing a lot of potential with `packages.Load(&packages.Config{Mode:packages.LoadTypes}, "...")` – Anonimoak May 12 '19 at 21:52
  • Internals can't be imported but they're still accessible for parsing/grepping/pprof - basically any mechanism you could use to analyse function calls. – Adrian May 13 '19 at 13:41