I'll present the steps that I would perform in such a case. Note that they aren't necessarily the most efficient and reliable ones although they should work in many cases. I'm assuming that the binary you want to examine isn't packed and obfuscated.
- Look for the imports. Sometimes the code you are looking for is just taken from external library. In this case just looking for its documentation will suffice. In case of PE files you can use Dependency Walker and ELF Library Viewer for ELF files.
- Open the file in disassembler (such as radare2 or IDA) and if debug symbols are attatched, you can search for the function with a name suggesting that it performs the activity you want to find.
- Search for strings. If you notice that some string is used when certain functionality is launched, you may just search for this string in disassembler and search for the references to it. Then, you can look around this area and you may find the code you are looking for.
In case all previous methods failed (most likely), it is time for dynamic analysis. Since you don't know where to set the breakpoints, you can set them at all the function calls in the program (possibly excluding library functions you aren't interested in). I wrote radare2 script performing exectly this task.
Assume we want to find out how Google Chrome parses xml files. I would modify this script to log each distinct function call and then simply continue. I would then open Google Chrome in debugger (possibly radare2 but can be any other you can write scripts for) and just wait a couple of seconds with empty page to gather all the functions it calls when doing "nothing special".
I would then rerun it, but this time with opening some xml file (for instance by drag and drop onto the empty page). Now, you can compare the files containing all the procedures called and see which extra ones are present in the second file. These (or at least some of them) should be responsible for parsing xml files.